《软件工程概述相关附件》由会员分享，可在线阅读，更多相关《软件工程概述相关附件（139页珍藏版）》请在金锄头文库上搜索。
1、软件工程概述相关附软件工程概述相关附件件第一章第一章 软件工程概述软件工程概述水利工程水利工程建筑工程建筑工程机械工程机械工程 软件工程软件工程软件工程软件工程 本章将介绍软件的地位和作用、软件的特点、软件本章将介绍软件的地位和作用、软件的特点、软件 的发展、软件危机、软件工程、软件生命周期以及软件的发展、软件危机、软件工程、软件生命周期以及软件过程等方面的问题和基本概念过程等方面的问题和基本概念传统工程传统工程新兴工程新兴工程气象工程气象工程生物工程生物工程1.1 软件的概念与特点软件的概念与特点1 1、软件、软件softwaresoft+ware软制品软制品(软体软体) 软件是计算机系统中
2、与硬件相互依存的另一部分。软件是计算机系统中与硬件相互依存的另一部分。 它包括它包括程序、数据程序、数据及其相关及其相关文档文档的完整集合。的完整集合。2 2、软件特点、软件特点. .软件是一种逻辑实体，而不是具体的物理实体软件是一种逻辑实体，而不是具体的物理实体. .软件的生产与硬件不同软件的生产与硬件不同. . . . 在软件的运行和使用期间，没有硬件那样的机械在软件的运行和使用期间，没有硬件那样的机械 磨损，老化问题磨损，老化问题磨合磨合调整调整磨损磨损用坏用坏修改点修改点实际曲线实际曲线理想曲线理想曲线硬件失效率曲线硬件失效率曲线时间时间失失效效率率时间时间失失效效率率软件失效率曲线软
3、件失效率曲线. .软件的成本相当昂贵软件的成本相当昂贵软件技术的发展落后于需求软件技术的发展落后于需求时间时间软软件件复复杂杂性性软件需求软件需求差距差距软件技术软件技术硬、软件成本比例的变化硬、软件成本比例的变化年份年份成本成本%软件软件软件软件1950197019851995硬件硬件3 3、软件的分类、软件的分类1 1、按软件的、按软件的、按软件的、按软件的功能功能功能功能进行划分进行划分进行划分进行划分系系统统软软件件支支撑撑软软件件应应用用软软件件支撑软件一般类型一般类型一般类型一般类型：文本编辑程序文本编辑程序文本编辑程序文本编辑程序文本格式化程序文本格式化程序文本格式化程序文本格式
4、化程序支持需求分析支持需求分析支持需求分析支持需求分析：PSL/PSAPSL/PSA问题描述问题描述问题描述问题描述语言语言语言语言关系数据库管理系关系数据库管理系关系数据库管理系关系数据库管理系统统统统支持设计支持设计支持设计支持设计：图形软件包图形软件包图形软件包图形软件包结构化流程图绘图结构化流程图绘图结构化流程图绘图结构化流程图绘图程序程序程序程序支持测试支持测试支持测试支持测试：静态分析器静态分析器静态分析器静态分析器测试覆盖检验程序测试覆盖检验程序测试覆盖检验程序测试覆盖检验程序支持实现支持实现支持实现支持实现：编辑程序编辑程序编辑程序编辑程序连接编辑程序连接编辑程序连接编辑程序连
5、接编辑程序支持管理支持管理支持管理支持管理：标准检验程序标准检验程序标准检验程序标准检验程序库管理程序库管理程序库管理程序库管理程序2 2、按软件的、按软件的、按软件的、按软件的规模规模规模规模进行划分进行划分进行划分进行划分 按开发软件所需的按开发软件所需的 人力、时间以及完成的人力、时间以及完成的 源代码行数。源代码行数。类别类别参加人数参加人数研制期限研制期限产品规模产品规模(源代码行数源代码行数)微型微型微型微型小型小型小型小型中型中型中型中型大型大型大型大型甚大型甚大型甚大型甚大型极大型极大型极大型极大型1 11 12-52-55-205-20100-1000100-10002000
6、-50002000-50001-41-4周周周周1-61-6周周周周1-21-2年年年年2-32-3年年年年4-54-5年年年年5-105-10年年年年约约约约500500行行行行 约约约约20002000行行行行 5000-500005000-50000行行行行5 5万万万万-10-10万行万行万行万行100100万行万行万行万行10001000万行万行万行万行 3 3、按软件、按软件、按软件、按软件开发开发开发开发划分划分划分划分软件项目开发软件产品开发上个世纪上个世纪60年代开始显现出来年代开始显现出来的的“软件危机软件危机”催生了催生了“软件工软件工程程”这门指导计算机软件开发和这门指
7、导计算机软件开发和维护的工程学科。维护的工程学科。1、什么是软件危机、什么是软件危机软件危机是指在计算机软件的软件危机是指在计算机软件的开发和维护过程中所遇到的一系列开发和维护过程中所遇到的一系列严重问题。严重问题。1.2 软件危机软件危机2、 产生软件危机的原因产生软件危机的原因 软件缺乏软件缺乏“可见性可见性”。 对用户需求没有完整准确的认识、不能适应用户对用户需求没有完整准确的认识、不能适应用户需求的变化。需求的变化。 缺乏对软件产品和开发过程的质量控制。缺乏对软件产品和开发过程的质量控制。 软件本身的可维护性差、开发商缺乏对维护的重视软件本身的可维护性差、开发商缺乏对维护的重视和准备、
8、缺乏正确的维护方法。和准备、缺乏正确的维护方法。导致导致“对软件开发成本、工作量、进度的估计对软件开发成本、工作量、进度的估计不准确不准确”；导致导致“用户对用户对已完成的已完成的软件系统不满意的软件系统不满意的现象经常发生现象经常发生”；导致导致“软件产品的质量往往靠不住软件产品的质量往往靠不住”；导致导致“软件常常不可维护软件常常不可维护”； 开发、维护过程中文档化工作做得不好、缺乏配开发、维护过程中文档化工作做得不好、缺乏配置管理。置管理。 硬件成本逐年下降，但软件成本居高不下。硬件成本逐年下降，但软件成本居高不下。 近近10来年，软件开发生产率有较大的提高，但计来年，软件开发生产率有较
9、大的提高，但计算机应用普及深入的速度更快。算机应用普及深入的速度更快。导致导致“软件通常不具有良好一致性的文档资料软件通常不具有良好一致性的文档资料”；导致导致“软件成本在计算机系统总成本中所占的软件成本在计算机系统总成本中所占的比例逐年上升比例逐年上升”；导致导致“软件开发生产率提高的速度，跟不上计软件开发生产率提高的速度，跟不上计算机应用普及深入的速度算机应用普及深入的速度”。3、 解决软件危机的途径解决软件危机的途径首先，应该对软件产品、系统有一个正确的认识。首先，应该对软件产品、系统有一个正确的认识。软件不仅仅是程序软件不仅仅是程序。IEEE对软件的定义：对软件的定义：Computer
10、programs,procedures,associateddocumentationanddatapertainingtotheoperationofacomputersystem.应该充分认识软件开发是一种应该充分认识软件开发是一种组织组织良好、良好、管理管理严密、严密、各类人员各类人员协同配合、共同完成的工程项目。协同配合、共同完成的工程项目。应该总结软件开发的成功经验，应用应该总结软件开发的成功经验，应用软件软件工程领域的先进思想、原理、方法、技术工程领域的先进思想、原理、方法、技术（针对具体公司、项目进行定制）。（针对具体公司、项目进行定制）。最后，应该（开发）、采用适当的软最后，应
11、该（开发）、采用适当的软件件工具工具，尤其是，尤其是CASE工具，来帮助完成软工具，来帮助完成软件开发工作。件开发工作。1.3 软件工程软件工程1、 软件工程介绍软件工程介绍软件工程是指导计算机软件开发和维护的一门软件工程是指导计算机软件开发和维护的一门工程学科。工程学科。采用工程的概念、原理、技术和方法来开发和维护采用工程的概念、原理、技术和方法来开发和维护软件，并融合其他学科、行业（如：管理、建筑、客户服软件，并融合其他学科、行业（如：管理、建筑、客户服务）的原理、技术和经验，以规范、高效、可度量、可管务）的原理、技术和经验，以规范、高效、可度量、可管理地开发出高质量的软件并维护它。理地开
12、发出高质量的软件并维护它。“经济经济”？软件工程特性：软件工程特性：更多关注大型程序的构造；更多关注大型程序的构造；关注对复杂性、风险的控制，关注可度关注对复杂性、风险的控制，关注可度量、可管理性；量、可管理性；重视软件系统的变化，要求软件系统对重视软件系统的变化，要求软件系统对变化的适应性，要求变动控制；变化的适应性，要求变动控制；强调软件开发的效率（涉及方法、工具）；强调软件开发的效率（涉及方法、工具）；强调合作开发、团队协作、沟通强调合作开发、团队协作、沟通重视用户（需求、反馈、技术支持等），重视用户（需求、反馈、技术支持等），重视和用户的交流；强调软件系统应能重视和用户的交流；强调软件
13、系统应能为用户提供价值、可用性；为用户提供价值、可用性；强调开发团队应具备相关行业的业务知强调开发团队应具备相关行业的业务知识、建立系统语境、通过有效沟通准确识、建立系统语境、通过有效沟通准确捕获用户需求。捕获用户需求。2、 软件工程的基本原理软件工程的基本原理Barry W. Boehm总结既有的软件工程准总结既有的软件工程准则，提出了则，提出了7条软件工程条软件工程基本原理基本原理：1 用分阶段的生命周期计划严格管理用分阶段的生命周期计划严格管理;2 坚持进行阶段评审坚持进行阶段评审;3 实行严格的产品控制（配置管理）实行严格的产品控制（配置管理）;4 采用现代（先进的）程序设计技术采用现
14、代（先进的）程序设计技术;5 结果应能清楚地审查结果应能清楚地审查;6 开发小组的成员应该少而精开发小组的成员应该少而精;7 承认不断改进软件工程实践的必要性承认不断改进软件工程实践的必要性;3、 软件工程的方法学软件工程的方法学通常把在软件生命周期全过程中使用的一通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学整套技术方法的集合称为方法学methodology。软件工程方法学包含软件工程方法学包含3个要素：方法、工具个要素：方法、工具和过程。和过程。* 软件工程传统途径软件工程传统途径（传统方法学）把软件生命周期的全过程依次划分为若干个阶段，顺序地完成每个阶段的任务。每一个阶
15、段的开始和结束都有准则或标准。每一个阶段的开始和结束都有准则或标准。采用结构化技术（结构化分析、设计和实采用结构化技术（结构化分析、设计和实现）来完成软件开发各阶段的各项任务。现）来完成软件开发各阶段的各项任务。每个阶段结束前都进行正式的技术审查和管理复每个阶段结束前都进行正式的技术审查和管理复审。审。技术审查技术审查帮助即时、尽早发现、纠正工程技术方面帮助即时、尽早发现、纠正工程技术方面的错误；保证软件质量。的错误；保证软件质量。软件错误的积累和放大效应图软件错误的积累和放大效应图目标主要是各个阶段的工程制品。目标主要是各个阶段的工程制品。如：系统范围是否恰当？技术方案是否可行？如：系统范围
16、是否恰当？技术方案是否可行？架构是否稳定？模型是否正确？架构是否稳定？模型是否正确？管理复审管理复审主要任务是对项目的开销、工作量、资主要任务是对项目的开销、工作量、资源（人力）、进度、风险等进行审查。源（人力）、进度、风险等进行审查。帮助决定开发是否继续，帮助对下一阶段的工作进行帮助决定开发是否继续，帮助对下一阶段的工作进行计划、对软件开发过程进行改进。计划、对软件开发过程进行改进。* 面向对象方法学面向对象方法学客观世界的问题都是由客观世界中的实体客观世界的问题都是由客观世界中的实体及实体间的关系构成的。及实体间的关系构成的。用计算机系统解用计算机系统解决客观世界的问决客观世界的问题，希望
17、实现解题，希望实现解法的解空间与问法的解空间与问题空间的结构尽题空间的结构尽可能一致。可能一致。传统语言提供的解空间传统语言提供的解空间对象不能满足要求。对象不能满足要求。面向对象方法学提供的解空面向对象方法学提供的解空间与客观世界问题空间的结间与客观世界问题空间的结构更一致。构更一致。面向对象方法是把数据和处理相结面向对象方法是把数据和处理相结合的方法。对象是由数据及可以施合的方法。对象是由数据及可以施加于这些数据的操作所构成的统一加于这些数据的操作所构成的统一体。体。面向对象方法把程面向对象方法把程序看作是相互协作序看作是相互协作而又彼此独立的对而又彼此独立的对象的集合；而不是象的集合；而
18、不是工作在数据上的过工作在数据上的过程或函数的集合。程或函数的集合。要点：要点：1 面向对象方法学认识问题空间，分析、解决面向对象方法学认识问题空间，分析、解决问题是用对象的观点。问题是用对象的观点。2 把对象抽象为类，类中定义数据和方法；类把对象抽象为类，类中定义数据和方法；类实例化即为对象。实例化即为对象。3 类层次结构类层次结构4 对象之间通过传递消息相互联系。对象之间通过传递消息相互联系。1.4 软件生命周期软件生命周期不同时期，不同的目标、任务。不同时期，不同的目标、任务。* 生命周期各阶段的基本任务生命周期各阶段的基本任务：1 问题定义问题定义 要解决的问题是什么？性质、范围？要解
19、决的问题是什么？性质、范围？ 客户的目标？软件系统的价值？客户的目标？软件系统的价值？最后系统分析员应提交开发方和客户都认可的书面最后系统分析员应提交开发方和客户都认可的书面报告。报告。2 可行性研究可行性研究对上一阶段提出的问题有可行的解决方案吗？3 需求分析需求分析用户有哪些具体需求？为了满足客户的需求，系统必须具备哪些功能？ 准确、完整地捕获用户需求。 系统分析员要提出经用户确认的系统逻辑模型。 技术可行性 经济可行性（时间、人员等） 操作可行性4 总体设计总体设计 / 架构设计架构设计要解决问题、满足用户需求，软件系统的总体架构是怎样的？ 首先，架构设计师应该考虑几种可能的解决方案（W
20、indows/Linux、.Net/J2EE、C/S or B/S、满足不同需求功能集的不同方案）。 选择、推荐最佳方案。 对确定的方案进行更具体的设计、描述（建立模型图、说明），包括对软件系统进行模块化，划分子系统、确定接口。5 详细设计详细设计软件系统、子系统/模块 具体应该是怎样的？ 算法（PDL语言、流程图等）。 数据结构、函数/过程、类的定义。 建立模型图。6 编码和单元测试编码和单元测试 用选定的编程语言书写程序（子系统/模块、类/组件、函数等），然后编译/翻译/汇编为机器代码。 对这些子系统/模块进行单元测试。7 综合测试综合测试软件是否实现了功能需求和非功能需求？ 集成测试 系
21、统测试 用户验收测试写：测试计划（测试策略、进度）、测试结果记录、测试结果分析、评估、报告。维护要求、审查、计划（维护方案）、维护、回归测试、维护记录、复查验收。8 维护维护 改正性维护 适应性维护 完善性维护 预防性维护1.5 软件过程软件过程软件过程是为了获得高质量软件所需要完成的一系列任务的框软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。架，它规定了完成各项任务的工作步骤。 通常使用生命周期模型简洁、直观地描述软件开发、运行、维护的过程。能力成熟度模型CMMCMM（CapabilityMaturityModel）即能）即能力成熟度模型，是美国卡
22、耐基梅隆大学软件工力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（程研究所（SEI）在美国国防部资助下于二十）在美国国防部资助下于二十世纪八十年代末建立的，用于评价软件机构的世纪八十年代末建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和软件过程能力成熟度的模型。此模型在建立和发展之初，主要目的在于发展之初，主要目的在于提供一种评价软件承提供一种评价软件承接方能力的方法，接方能力的方法，为大型软件项目的招投标活为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到动提供一种全面而客观的评审依据。而发展到后来，又同时被后来，又同时被软件组织用于改进其软件过程。软件组织
23、用于改进其软件过程。软件组织的成熟与不成熟 1.不成熟的软件组织不成熟的软件组织软软件件过过程程一一般般并并不不预预先先计计划划，而而是是在在项项目目进进行中由实际工作人员及管理员临时计划行中由实际工作人员及管理员临时计划有有时时，即即使使软软件件过过程程已已计计划划好好，仍仍不不按按计计划划执行执行没没有有一一个个客客观观的的基基准准来来判判断断产产品品质质量量，或或解解决产品和过程中的问题决产品和过程中的问题对对软软件件过过程程步步骤骤如如何何影影响响软软件件质质量量，一一无无所所知知，产产品品质质量量得得不不到到保保证证。而而且且，一一些些提提高高质质量量的的环环节节，如如检检查查、测测
24、试试等等经经常常由由于于要要赶赶进度而减少或取消进度而减少或取消产产品品在在交交付付前前，对对客客户户来来说说，一一切切都都是是不不可可见的见的没没有有长长远远目目标标，管管理理员员通通常常只只关关注注解解决决任任何何当前的危机当前的危机由由于于没没有有实实事事求求是是地地估估计计进进度度、预预算算，因因此此他他们们经经常常超超支支、超超时时。当当最最后后期期限限临临近近，他他们们往往往往在在功功能能性性和和质质量量上上妥妥协协，或或以以加加班班加加点方式赶进度点方式赶进度2.成熟的软件组织成熟的软件组织具具有有全全面面而而充充分分的的组组织织和和管管理理软软件件开开发发和和维维护护过过程程的
25、能力的能力管管理理员员监监视视软软件件产产品品的的质质量量以以及及生生产产这这些些产产品品的的过过程程制制定定了了一一系系列列客客观观基基准准来来判判别别产产品品质质量量，并并分分析析产产品和过程中的问题品和过程中的问题进进度度和和预预算算可可以以按按照照以以前前积积累累的的经经验验来来制制定定，结结果果可可行行。预预期期的的成成本本、进进度度、功功能能与与性性能能和和质质量量都都能能实现，并达到目的实现，并达到目的能能准准确确及及时时地地向向工工作作人人员员通通报报实实际际软软件件过过程程，并并按按照计划有规则地照计划有规则地(前后一致，不互相矛盾前后一致，不互相矛盾)工作工作凡规定的过程都
26、编成文档凡规定的过程都编成文档软软件件过过程程和和实实际际工工作作方方法法相相吻吻合合。必必要要时时，过过程程定定义义会会及及时时更更新新，通通过过测测试试，或或者者通通过过成本成本-效益分析来改进过程。效益分析来改进过程。全全体体人人员员普普遍遍地地、积积极极地地参参与与改改进进软软件件过过程程的的活活动动。在在组组织织内内部部的的各各项项目目中中，每每人人在在软软件件过过程程中中的的职职责责都都十十分分清清晰晰而而明明确确，每每人人各各守守其其责责，协协同同工工作作，有有条条不不紊紊，甚甚至至能能预预见见和防范问题的发生。和防范问题的发生。软件过程成熟度等级 CMM提提供供了了一一个个成成
27、熟熟度度等等级级框框架架：1级级-初初始始级级、2级级-可可重重复复级级、3级级-已已定定义义级级、4级级-已管理级和已管理级和5级级-优化级。优化级。1.初始（初始（initial）级：）级：软软件件过过程程的的特特点点是是无无秩秩序序的的，甚甚至至是是混混乱乱的的。几几乎乎没没有有什什么么过过程程是是经经过过妥妥善善定定义义的的，成成功功往往依赖于个人或小组的努力。往往依赖于个人或小组的努力。2.可重复（可重复（repeatable）级：）级：建建立立了了基基本本的的项项目目管管理理过过程程来来跟跟踪踪成成本本、进进度度和和功功能能特特性性。制制定定了了必必要要的的过过程程纪纪律律，能能重
28、复早先类似应用项目取得的成功。重复早先类似应用项目取得的成功。3.已定义（已定义（defined）级：）级：己己将将管管理理和和工工程程活活动动两两方方面面的的软软件件过过程程文文档档化化、标标准准化化，并并综综合合成成该该机机构构的的标标准准软软件件过过程程。所所有有项项目目均均使使用用经经批批准准、剪剪裁裁的的标标准准软软件件过过程程来来开开发发和和维维护护软件。软件。4.已管理（已管理（managed）级：）级：收收集集对对软软件件过过程程和和产产品品质质量量的的详详细细度度量量值值，对对软软件件过程和产品都有定量的理解和控制。过程和产品都有定量的理解和控制。5.优化（优化（optimi
29、zing）级：）级：整整个个组组织织关关注注软软件件过过程程改改进进的的持持续续性性、预预见见及及增增强强自自身身，防防止止缺缺陷陷及及问问题题的的发发生生。过过程程的的量量化化反反馈馈和和先进的新思想、新技术促使过程不断改进。先进的新思想、新技术促使过程不断改进。5.5.优化级优化级4.4.已管理级已管理级3.3.已定义级已定义级2.2.可重复级可重复级1.1.初始级初始级标标准准、一一致致的过程的过程有纪律有纪律的过程的过程可预测的过程可预测的过程持续改进的过程持续改进的过程软件过程成熟度软件过程成熟度的的5 5个等级个等级成熟度等级成熟度等级关键过程域关键过程域共同特性共同特性关键实践关
30、键实践包含包含划分为划分为包含包含过程能力过程能力表明表明目标目标实现实现实施或制度化实施或制度化解决解决活动或基础设施活动或基础设施描述描述CMM结构结构能力成熟度模型的结构能力成熟度模型的结构能力成熟度模型的结构成成熟熟度度等等级级表表明明了了一一个个软软件件组组织织的的过过程程能能力力的的水水平平。除除初初始始级级外外，每每个个成成熟熟度度等等级级都都包包含含若若干干个个关关键键过过程程域域（KeyProcessArea，简称简称KPA）（见表）（见表1.2）达达到到某某个个成成熟熟度度级级别别，该该级级别别（以以及及较较低低级级别别）的的所所有有关关键键过过程程域域都都必必须须得得到到
31、满满足足，并并且过程必须实现制度化。且过程必须实现制度化。CMM提提供供了了18个个关关键键过过程程域域，每每个个关关键键过过程程域域都都有有一一组组对对改改进进过过程程能能力力非非常常重重要要的的目目标标，并确定了一组相应的关键实践并确定了一组相应的关键实践目目标标说说明明了了每每一一个个关关键键过过程程域域的的范范围围、界界限限和意义。和意义。关关键键实实践践描描述述了了建建立立一一个个过过程程能能力力必必须须完完成成的的活活动动和和必必须须具具备备的的基基础础设设施施，完完成成了了这这些些关关键键实实践践就就达达到到了了相相应应关关键键过过程程域域的的目目标标，该关键过程域也就得到了满足
32、。该关键过程域也就得到了满足。每每个个关关键键过过程程域域的的关关键键实实践践都都是是按按照照五五个个共共同同特特性性（执执行行约约定定，执执行行能能力力，执执行行活活动动，测测量量和和分分析析，验验证证实实现现）进进行行组组织织的的，主主要要解决关键实践的实施或制度化问题。解决关键实践的实施或制度化问题。共共同同特特性性将将描描述述关关键键过过程程域域的的关关键键实实践践组组织织起起来来。共共同同特特性性是是一一些些属属性性，指指明明一一个个关关键键过过程程域域的的执执行行和和规规范范化化是是否否有有效效、可可重重复复和和可可持持续续。共共有有5个个共共同同特特性性:执执行行约约定定，执执行
33、行能能力力，执行活动，测量和分析，验证实现。执行活动，测量和分析，验证实现。1)执行约定执行约定：执执行行约约定定描描述述机机构构为为确确保保过过程程的的建建立立和和持持续续而而必必须须采采取取的的一一些些措措施施。典典型型内内容容包包括括建建立立机机构构策略和领导关系。策略和领导关系。2)执行能力执行能力：执执行行能能力力描描述述了了项项目目或或机机构构完完整整地地实实现现软软件件过过程程所所必必须须有有的的先先决决条条件件。典典型型内内容容包包括括资资源源、机构结构和培训。机构结构和培训。3)执行活动执行活动：执执行行活活动动描描述述了了执执行行一一个个关关键键过过程程域域所所必必需需的的
34、活活动动、任任务务和和规规程程。典典型型内内容容包包括括制制定定计计划划和和规程、执行和跟踪以及必要时采取纠正措施。规程、执行和跟踪以及必要时采取纠正措施。4)测量和分析测量和分析：测测量量和和分分析析描描述述了了为为确确定定与与过过程程有有关关的的状状态态所所需需的的基基本本测测量量实实践践。这这些些测测量量可可用用来来控控制制和和改改进过程。典型内容包括可能采用的测量实例。进过程。典型内容包括可能采用的测量实例。5)验证实现验证实现：验验证证实实现现描描述述了了为为确确保保执执行行的的活活动动与与已已建建立立的的过过程程一一致致所所采采取取的的步步骤骤。典典型型内内容容包包括括管管理理部部
35、门和软件质量保证组实施的评审和审核。门和软件质量保证组实施的评审和审核。在在执执行行活活动动这这个个共共同同特特性性中中的的实实践践描描述述了了建建立立一一个个过过程程能能力力所所必必须须完完成成的的活活动动。所所有有其其他他实实践践共共同同形形成成了了一一个个使使机机构构能能将将执执行行活活动动中中描描述的实践进行规范化的基础。述的实践进行规范化的基础。各各关关键键过过程程域域的的详详细细描描述述，参参见见能能力力成成熟熟度度模模型型（CMM）：软软件件过过程程改改进进指指南南，卡卡耐耐基基梅梅隆隆大大学学软软件件工工程程研研究究所所编编著著，刘刘孟孟仁仁等等译，电子工业出版社出版。译，电子
36、工业出版社出版。缺陷预防缺陷预防技术更新管理技术更新管理过程更改管理过程更改管理优化级优化级定量过程管理定量过程管理软件质量管理软件质量管理已管理级已管理级机构过程焦点机构过程焦点机构过程定义机构过程定义培训大纲培训大纲综合软件管理综合软件管理软件产品工程软件产品工程组间协调组间协调同行评审同行评审已定义级已定义级需求管理需求管理软件项目计划软件项目计划软件项目跟踪和监督软件项目跟踪和监督软件分包合同管理软件分包合同管理软件质量保证软件质量保证软件配置管理软件配置管理可重复级可重复级初始级初始级能能力力成成熟熟度度级级别别中中的的关键过程域关键过程域关键过程域实例机构过程焦点机构过程焦点第第3
37、级的关键过程域：级的关键过程域：已定义级已定义级机机构构过过程程焦焦点点的的目目的的是是，为为能能改改进进机机构构整整体体软软件件过过程程能能力力的的软软件件过过程活动程活动建立机构的职责建立机构的职责。机机构构过过程程焦焦点点包包括括，建建立立和和维维护护机机构构的的软软件件过过程程和和项项目目软软件件过过程程（之之间间）的的默默契契关关系系，并并协协调调有有关关评评估估、开开发发、维维护护和和改改进进这这些些过过程程的活动。的活动。机机构构提提供供长长期期的的约约定定和和资资源源，以以协协调调现现在在和和将将来来的的软软件件项项目目的的软软件件过过程程的的开开发发和和维维护护。该该项项工工
38、作作由由某某个个小小组组实实施施，例例如如软软件件工工程程过过程程组组。它它负负责责机机构构的的软软件件过过程程活活动动，特特别别是是负负责责开开发发和和维维护护机机构构标标准准软软件件过过程程和和相相关关过过程程资资源源（如如在在机机构构过过程程定定义义关关键键过过程程域域中中说说明明的的），并并协协调软件项目的过程活动。调软件项目的过程活动。目标目标目目标标1：机机构构内内部部软软件件过过程程的的制制定定和和改改进进活活动协调一致。动协调一致。目目标标2：相相对对于于过过程程标标准准，所所使使用用的的软软件件过过程的优势和薄弱环节标识清楚。程的优势和薄弱环节标识清楚。目目标标3：机机构构级
39、级的的过过程程开开发发和和改改进进活活动动有有计计划。划。执行约定执行约定约约定定1：机机构构遵遵循循书书面面的的管管理理策策略略，协协调调整整个个机构范围内的软件过程开发和改进活动。机构范围内的软件过程开发和改进活动。该策略一般规定该策略一般规定:1.建建立立一一个个小小组组，负负责责机机构构级级的的软软件件过过程程活动，使这些活动与各项目协调一致。活动，使这些活动与各项目协调一致。2.定定期期评评估估项项目目所所使使用用的的软软件件过过程程，以以确确定其优势和薄弱环节。定其优势和薄弱环节。3.对对机机构构标标准准软软件件过过程程进进行行合合理理地地剪剪裁裁，以得到项目使用的软件过程。以得到
40、项目使用的软件过程。关关于于机机构构标标准准软软件件过过程程，参参见见综综合合软软件件管理关键过程域的活动管理关键过程域的活动1。4.每个项目的软件过程、工具和方法的改每个项目的软件过程、工具和方法的改进和其他有用信息，可用于其他项目。进和其他有用信息，可用于其他项目。约约定定2：上上级级管管理理部部门门倡倡导导和和支支持持机机构构的的软软件件过程开发和改进活动。过程开发和改进活动。上级管理部门上级管理部门：1.向向机机构构成成员员和和负负责责人人说说明明有有关关软软件件过过程程活动的约定。活动的约定。2.制制定定资资金金、人人员员配配备备和和其其他他资资源源的的长长期期计划和约定。计划和约定
41、。3.制制定定管管理理和和执执行行有有关关软软件件过过程程开开发发和和改改进活动的策略。进活动的策略。约约定定3：上上级级管管理理部部门门监监督督机机构构的的软软件件过过程程开开发和改进活动。发和改进活动。l.确确保保机机构构标标准准软软件件过过程程满满足足企企业业目目标标和和策略。策略。2.提提出出关关于于软软件件过过程程开开发发和和改改进进活活动动优优先先次序的建议。次序的建议。3.参与制定软件过程开发和改进计划。参与制定软件过程开发和改进计划。a.上上级级管管理理部部门门与与更更高高层层人人员员和和负负责责人人共同协调软件过程需求及问题共同协调软件过程需求及问题b.上上级级管管理理部部门
42、门与与该该机机构构负负责责人人进进行行协协调，以获得负责人和机构成员的支持和参与调，以获得负责人和机构成员的支持和参与执行能力执行能力能力能力1：有一个负责机构的软件过程活动的小组。有一个负责机构的软件过程活动的小组。一一个个小小组组是是一一些些部部门门、负负责责人人和和人人员员的的组组合合，负负责责一一组组任任务务和和活活动动。小小组组的的规规模模可可以以不不同同，既既可可以以是是单单个个兼兼职职的的人人，也也可可以以是是多多个个来来自自不不同同部部门门的的兼兼职职人人员员，也也可可以以由由几几个个专专职职人人员员组组成成。组组成成小小组组时时考考虑虑的的因因素素包包括括：分分派派的的任任务
43、务和和活活动动、项项目目规规模模、机机构构结结构构和和机机构构文文化化。某某些些小小组组，如如软软件件质质量量保保证证组组，集集中中关关注注项项目目活活动动;而而其其他他一一些些小小组组，例例如如软件工程过程组，集中关注机构范围内的活动。软件工程过程组，集中关注机构范围内的活动。1.条条件件可可能能时时，小小组组成成员员以以专专职职工工作作的的软软件件专专业业人人员为核心，并尽可能有其他的兼职人员支持。员为核心，并尽可能有其他的兼职人员支持。该小组最一般的例子是软件工程过程（该小组最一般的例子是软件工程过程（SEPG）。2.小组成员中有小组成员中有软件工程软件工程及软件及软件相关科目的代表相关
44、科目的代表。软件工程及软件相关科目的实例有软件工程及软件相关科目的实例有：软件需求分析软件需求分析软件设计软件设计程序编码程序编码软件测试软件测试软件配置管理软件配置管理软件质量保证软件质量保证能能力力2：为为实实施施机机构构的的软软件件过过程程活活动动提提供供了了充充足足的的资资源和资金。源和资金。1.委派在特定领域具有特长的人员支持该小组。委派在特定领域具有特长的人员支持该小组。特定领域的实例有：特定领域的实例有：软件重用软件重用计算机辅助软件工程技术计算机辅助软件工程技术(CASE)测量测量培训课程开设培训课程开设2.有支持该机构软件过程活动的工具。有支持该机构软件过程活动的工具。支持工
45、具的实例有：支持工具的实例有：统计分析工具统计分析工具桌面出版工具桌面出版工具数据库管理系统数据库管理系统过程建模工具过程建模工具能能力力3：负负责责机机构构软软件件过过程程活活动动的的小小组组成成员员接接受过实施这些活动所需的培训。受过实施这些活动所需的培训。培训的实例有：培训的实例有：软件工程实践软件工程实践过程控制技术过程控制技术机构过程变动管理机构过程变动管理软件过程计划、管理和监督软件过程计划、管理和监督技术转变技术转变参见培训大纲关键过程域参见培训大纲关键过程域能能力力4：软软件件工工程程组组和和其其他他软软件件相相关关小小组组的的成成员员接接受受过过机机构构软软件件过过程程活活动
46、动及及其其在在这这些些活活动动中的任务方面的定向培训。中的任务方面的定向培训。参见培训大纲关键过程域执行活动执行活动活活动动1：定定期期评评估估软软件件过过程程，并并根根据据评评估估结结果果制制定定行行动计划。动计划。评评估估一一般般每每隔隔一一年年、一一年年半半至至三三年年进进行行一一次次。评评估估可可针针对对机机构构中中所所使使用用的的所所有有软软件件过过程程，也也可可通通过过对对过过程程和和项项目目进进行行抽抽样样评评估估。评评估估机机构构软软件件过过程程能力的方法实例之一是能力的方法实例之一是SEI软件过程评估方法。软件过程评估方法。行动计划标识行动计划标识：涉及哪些评估结果涉及哪些评
47、估结果针对评估结果实施更改软件过程的准则针对评估结果实施更改软件过程的准则负责实施更改的小组或个人负责实施更改的小组或个人活活动动2：机机构构制制定定和和维维护护它它的的软软件件过过程程开开发发和和改改进进活活动的计划。动的计划。该计划：该计划：1.以以软软件件过过程程评评估估后后的的行行动动计计划划和和其其他他的的机机构构过过程程改改进倡议为基础。进倡议为基础。2.确定要实施的活动及实施这些活动的进度。确定要实施的活动及实施这些活动的进度。3.确定负责这些活动的小组和个人。确定负责这些活动的小组和个人。4.确定所需的资源，包括人员配备和工具。确定所需的资源，包括人员配备和工具。5.初始发布和
48、有大改动时通过同行评审。初始发布和有大改动时通过同行评审。参见同行评审关键过程域。参见同行评审关键过程域。6.机构的软件负责人和上级负责人评审认可。机构的软件负责人和上级负责人评审认可。活活动动3：在在机机构构级级协协调调关关于于机机构构和和项项目目的的软软件件过程的开发和改进活动。过程的开发和改进活动。涉及的软件过程有：涉及的软件过程有：1.机构标准软件过程。机构标准软件过程。关关于于机机构构标标准准过过程程，参参见见机机构构过过程程定定义义关关键过程域的活动键过程域的活动1和活动和活动2。2.项目定义的软件过程。项目定义的软件过程。关关于于项项目目定定义义的的软软件件过过程程。参参见见综综
49、合合软软件件管理关键过程域的活动管理关键过程域的活动1和活动和活动2。活活动动4：在在机机构构级级协协调调有有关关软软件件过过程程数数据据库库的的使用。使用。机机构构的的软软件件过过程程数数据据库库用用来来收收集集机机构构和和项项目的软件过程以及生成的软件产品的信息。目的软件过程以及生成的软件产品的信息。关关于于机机构构的的软软件件过过程程数数据据库库，参参见见机机构构过过程程定义关键过程域的活动定义关键过程域的活动5。活活动动5：监监控控和和评评价价机机构构中中限限制制使使用用的的新新过过程程、方方法法和和工工具具。合合适适时时，推推广广到到机机构构的的其其他他部分。部分。活活动动6：在在机
50、机构构内内协协调调机机构构和和项项目目的的软软件件过过程程的培训。的培训。1.制制定定有有关关机机构构和和项项目目软软件件过过程程的的专专题题培训计划。培训计划。2.合合适适时时，培培训训由由负负责责机机构构软软件件过过程程活活动动的的小小组组（如如软软件件工工程程过过程程组组）或或培培训训小小组准备和实施。组准备和实施。参见培训大纲关键过程域。参见培训大纲关键过程域。活活动动7：向向与与实实施施软软件件过过程程有有关关的的小小组组通通报报机机构构和和项项目目中中软软件件过过程程开开发发和和改改进进活活动动的的情情况。况。通报方式的实例有：通报方式的实例有：过程电子公告板过程电子公告板过程咨询
51、委员会过程咨询委员会工作小组工作小组信息交流会信息交流会调查调查过程改进组过程改进组日常讨论日常讨论测量和分析测量和分析测测量量1：测测量量机机构构的的软软件件过过程程开开发发和和改改进进活活动动的状态的状态测量的实例有：测量的实例有：机机构构在在过过程程评评估估、开开发发和和改改进进活活动动中中已已完完成成的的工工作作、工工作作量量和和耗耗费费的的资资金金，与与计计划划相相比比较较每每次次软软件件过过程程的的评评估估结结果果，与与以以前前的的评评估估结结果和建议相比较果和建议相比较验证实现验证实现验验证证1：上上级级管管理理部部门门定定期期评评审审软软件件过过程程开开发发和和改改进进活动。活
52、动。上上级级管管理理部部门门实实施施定定期期评评审审的的主主要要目目的的是是适适当当地地、及及时时地地掌掌握握软软件件过过程程活活动动。在在满满足足机机构构需需求求的的前前提提下下，只只要要有有适适当当的的机机制制来来报报告告异异常常情情况况，评审的时间间隔就尽可能长些。评审的时间间隔就尽可能长些。1.对对照照计计划划，评评审审有有关关开开发发和和改改进进软软件件过过程程活活动动的进展和状态。的进展和状态。2.讨论低层不能解决的冲突和问题。讨论低层不能解决的冲突和问题。3.指定和评审行动措施，并跟踪到关闭。指定和评审行动措施，并跟踪到关闭。4.编编写写评评审审的的总总结结报报告告，并并分分发发
53、给给相相关关的的小小组组和和个人。个人。能力成熟度模型集成CMMICapability Maturity Model IntegrationCMM的的成成功功导导致致了了各各种种模模型型的的衍衍生生，每每一一种种模模型型都探讨了某一特定领域中的过程改进问题都探讨了某一特定领域中的过程改进问题SW-CMM：适用于软件开发：适用于软件开发SE-CMM：系统工程能力成熟度模型：系统工程能力成熟度模型SA-CMM：适用于软件获取：适用于软件获取SECAM：系统工程能力评估模型：系统工程能力评估模型PeopleCMM：讨讨论论软软件件组组织织吸吸引引、开开发发、激激励励、组组织织和和留留住住人人才的能力
54、才的能力EIA/IS731：替代：替代SW-CMM和和SECAMIPD-CMM：适用于集成化产品开发：适用于集成化产品开发FAA-iCMM：集成了：集成了SE-CMM、SA-CMM、SW-CMM相相应应的的国国际际标标准准：ISO/IEC12207（软软件件生生存存周周期期过过程程）、ISO/IEC15288（系系统统生生存存周周期期过过程程）、ISO/IEC15504（软软件件过过程程评估）评估）模模型型的的繁繁衍衍导导致致模模型型框框架架、术术语语等等方方面面的的矛矛盾和不一致盾和不一致包包含含在在当当代代工工程程中中各各种种各各样样的的学学科科和和工工程程是是密密切切交交叉叉在在一一起起
55、的的，应应用用不不同同模模型型时时效效率率低低下且容易混淆，常常要付出极其昂贵的代价下且容易混淆，常常要付出极其昂贵的代价美美国国国国防防部部、美美国国国国防防工工业业委委员员会会和和SEI/CMU于于1998年年启启动动CMMI项项目目，希希望望CMMI是是若若干干过过程程模模型型的的综综合合和和改改进进，是是支支持持多多个个工工程程学学科科和和领领域域的的系系统统的的、一一致致的的过过程程改改进进框框架架，能能适适应应现现代代工工程程的的特特点点和和需需要要，能提高过程的质量和工作效率能提高过程的质量和工作效率2000年年 发发 布布 第第 一一 个个 CMMI模模 型型 CMMI-SE/
56、SW/IPPD V1.0： 集集 成成 了了 SW-CMM、EIA/IS731、IPDCMMV0.982002年年1月月发发布布CMMI-SE/SW/IPPDV1.1，美美国国国国防防工工业业委委员员会会在在第第一一届届CMMI国国际际研研讨讨会会上上宣宣布布，CMMIV1.1将将至至少少稳稳定定五五年年不变不变CMMI模模型型为为每每个个学学科科的的组组合合都都提提供供两两种种表表示法：阶段式模型和连续式模型示法：阶段式模型和连续式模型阶段式模型阶阶段段式式模模型型的的结结构构类类同同于于软软件件CMM，它它关关注组织的成熟度，其成熟度等级如下图所示注组织的成熟度，其成熟度等级如下图所示5优
57、化的优化的4定量管理的定量管理的3已定义的已定义的2已管理的已管理的1初始的初始的过程不可预测且缺乏控制过程不可预测且缺乏控制过程为项目服务过程为项目服务过程为组织服务过程为组织服务过程已度量和控制过程已度量和控制集中于过程改进集中于过程改进阶段式成熟度等级阶段式成熟度等级过程域过程域2过程域过程域n成熟度等级成熟度等级过程域过程域1执行的能力执行的能力执行的承诺执行的承诺定向实现定向实现验证实现验证实现特定目标特定目标共性目标共性目标特定实践特定实践共性实践共性实践公共特征公共特征CMMIV1.1的的24个过程域的分组如下：个过程域的分组如下：成熟度等级成熟度等级过程域过程域已管理的已管理的
58、需求管理需求管理REQM，项目计划，项目计划PP，项目监督和控，项目监督和控制制PMC，供应商合同管理，供应商合同管理SAM，度量和分析，度量和分析MA，过程和产品质量保证，过程和产品质量保证PPQA，配置管理，配置管理CM已定义的已定义的需求开发需求开发RD，技术解决方案，技术解决方案TS，产品集成，产品集成PI，验证验证VER，确认，确认VAL，组织级过程焦点，组织级过程焦点OPF，组，组织级过程定义织级过程定义OPD，组织级培训，组织级培训OT，集成化项，集成化项目管理目管理IPM，风险管理，风险管理RSKM，集成化建组，集成化建组IT，决策分析和解决方案决策分析和解决方案DAR，组织级
59、集成环境，组织级集成环境OEI定量管理的定量管理的 组织级过程性能组织级过程性能OPP，项目定量管理，项目定量管理QPM优化的优化的组织级改革和实施组织级改革和实施OID，因果分析和解决方案，因果分析和解决方案CAR连续式模型连连续续式式模模型型关关注注每每个个过过程程域域的的能能力力，一一个个组组织织对对不不同同的的过过程程域域可可以以达达到到不不同同的的过过程程域域能能力等级（力等级（Capabilitylevel，CL）。）。CMMI中中包包括括六六个个过过程程域域能能力力等等级级，等等级级号号为为05。能能力力等等级级表表明明了了单单个个过过程程域域中中组组织织执行的好坏程度。执行的好
60、坏程度。允允许许组组织织对对连连续续式式模模型型的的过过程程域域进进行行剪剪裁裁，也允许对不同的过程域采用不同的能力等级也允许对不同的过程域采用不同的能力等级下图给出了某组织的过程域能力等级下图给出了某组织的过程域能力等级能力等级特征示意图能力等级特征示意图CL0未完成的未完成的CL1已执行的已执行的CL2已管理的已管理的CL3已定义的已定义的CL4定量管理的定量管理的CL5优化的优化的过程域过程域RSKMIPMSAMPMCPPITQPM能能力力等等级级包包括括共共性性目目标标及及相相关关的的共共性性实实践践，这这些些实实践践在在过过程程域域内内被被添添加加到到特特定定目目标标和和实实践践中中
61、。当当组组织织满满足足过过程程域域的的特特定定目目标标和和共共性性目目标标时时，就就说说该该组组织织达达到到了了那那个个过过程程域的能力等级。域的能力等级。能能力力等等级级25的的名名字字与与成成熟熟度度等等级级25同同名名，但但含含义义不不同同。能能力力等等级级可可以以独独立立地地应应用用于于任任何何单单独独的的过过程程域域，任任何何一一个个能能力力等等级级都都必必须须满满足足比比它它等等级级低低的的能能力力等等级级的的所所有准则，各能力等级的含义简述如下：有准则，各能力等级的含义简述如下：CL0未未完完成成的的：过过程程域域未未执执行行或或未未达达到到CL1中定义的所有目标。中定义的所有目
62、标。CL1已已执执行行的的：其其共共性性目目标标是是过过程程将将可可标标识识的的输输入入工工作作产产品品转转换换成成可可标标识识的的输输出出工工作作产产品，以实现支持过程域的特定目标。品，以实现支持过程域的特定目标。CL2已已管管理理的的：其其共共性性目目标标集集中中于于已已管管理理的的过过程程的的制制度度化化。根根据据组组织织级级政政策策规规定定过过程程的的运运作作将将使使用用哪哪个个过过程程，项项目目遵遵循循已已文文档档化化的的计计划划和和过过程程描描述述，所所有有正正在在工工作作的的人人都都有有权权使使用用足足够够的的资资源源，所所有有工工作作任任务务和和工工作作产产品品都被监控、控制和
63、评审。都被监控、控制和评审。CL3 已定义的：其共性目标集中于已定义的过程的制度化。 过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对该过程的改进上。CL4 定量管理的：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则。CL5 优化的：使用量化（统计学）手段改编和优化过程域，以对付客户要求的改变和持续改进计划中的过程域的功效。连连续续式式模模型型将将24个个过过程程域域划划分分为为过过程程管管理理、项目管理、工程和支持四个过程组：项目管理、工程和支持四个过程组：
64、连续式分组连续式分组过程域过程域过程管理过程管理组织级过程焦点组织级过程焦点OPF，组织级过程定义，组织级过程定义OPD，组织级培训组织级培训OT，组织级过程性能，组织级过程性能OPP，组织级，组织级改革和实施改革和实施OID项目管理项目管理项目计划项目计划PP，项目监督和控制，项目监督和控制PMC，供应商合，供应商合同管理同管理SAM，集成化项目管理，集成化项目管理IPM，风险管理，风险管理RSKM，集成化建组，集成化建组IT，项目定量管理，项目定量管理QPM工工程程需求管理需求管理REQM，需求开发，需求开发RD，技术解决方案，技术解决方案TS，产品集成，产品集成PI，验证，验证VER，确
65、认，确认VAL支支持持配置管理配置管理CM，过程和产品质量保证，过程和产品质量保证PPQA，度，度量和分析量和分析MA，决策分析和解决方案，决策分析和解决方案DAR，组织，组织级集成环境级集成环境OEI，因果分析和解决方案，因果分析和解决方案CAR内容摘要计算机软件软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境软件过程模型软件过程模型是软件开发全部过程、活动和任务的结构框架也称软件开发模型或软件生存周期模型软件过程模型典型的软件过程模型有：瀑布模型瀑布模型（waterfallmodel）演化模型演化模型（evolutionarymodel）增量模型（增量模型（incremental
66、model）原型模型（原型模型（prototypingmodel)螺旋模型（螺旋模型（spiralmodel）喷泉模型喷泉模型（waterfountainmodel）基于构件的开发模型基于构件的开发模型（component-baseddevelopmentmodel）形式方法模型形式方法模型（formalmethodsmodel）瀑布模型瀑布模型系统工程系统工程需求分析需求分析与规约与规约设计与设计与规约规约编码与编码与单元测试单元测试集成测试集成测试系统测试系统测试运行与运行与维护维护1970年年W.Royce提出瀑布模型提出瀑布模型特征特征接受上一阶段的结果作为本阶段的输入接受上一阶段的结
67、果作为本阶段的输入利用这一输入实施本阶段应完成的活动利用这一输入实施本阶段应完成的活动对本阶段的工作进行评审对本阶段的工作进行评审将本阶段的结果作为输出，传递给下一阶段将本阶段的结果作为输出，传递给下一阶段缺点缺点缺乏灵活性，难以适应需求不明确或需求经常缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发变化的软件开发开发早期存在的问题往往要到交付使用时才发开发早期存在的问题往往要到交付使用时才发现，维护代价大现，维护代价大许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功。可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型
68、（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品。演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程。演化模型适用于对软件需求缺乏准确认识的情况。典型的演化模型有：增量模型、原型模型、螺旋模型。演化模型增量模型项目日历时间项目日历时间软软件件功功能能性性和和特特征征1 12 23 34 45 5第第2 2次增量发布次增量发布增量增量2 21 12 23 34 45 5第第n n次增量发布次增量发布增量增量n n1 12 23 34 45 5第第1 1次
69、增量发布次增量发布增量增量1 15 5部署（发布，反馈）部署（发布，反馈）4 4构造（编码，测试）构造（编码，测试）3 3建模（分析，设计）建模（分析，设计）2 2计划计划1 1交流交流增量模型将软件的开发过程分成若干个增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序日程时间交错的线性序列，每个线性序列产生软件的一个可发布的列产生软件的一个可发布的“增量增量”版版本，后一个版本是对前一版本的修改和本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生补充，重复增量发布的过程，直至产生最终的完善产品。最终的完善产品。增量模型融合了增量模型融合了瀑布模型的基本成分
70、瀑布模型的基本成分（重复地应用）和（重复地应用）和演化模型的迭代特征演化模型的迭代特征增量模型强调每一个增量都增量模型强调每一个增量都发布发布一个一个可可运行的产品运行的产品增量模型特别适用于：增量模型特别适用于：需求经常变化的软件开发需求经常变化的软件开发市场急需而开发人员和资金不能在设定市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的的市场期限之前实现一个完善的产品的软件开发软件开发增量模型能有计划地管理技术风险，如增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技早期增量版本中避免采用尚未成熟的技术术原型（原型（prototype）是预期系统的一个可
71、执行版本，）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。束，其目的是能快速、低成本地构建原型。原型方法从软件工程师与客户的交流开始，其目的原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型。速设计的方
72、式对其建模，并构建原型。被开发的原型应交付给客户试用，并收集客户的反被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。范围的时候，进入下一轮原型的迭代开发。原型模型部署交付和反馈部署交付和反馈构建原型构建原型交流交流快速设计方式建模快速设计方式建模快速计划快速计划原型模型原型模型原型的类型：原型的类型：探索型（探索型（exploratoryprototyping）其目的是要弄清目标系统的要
73、求，确定所希望其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性的特性，并探讨多种方案的可行性实验型（实验型（experimentalprototyping）其目的是验证方案或算法的合理性，它是在大其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规模开发和实现前，用于考核方案是否合适，规格说明是否可靠。规格说明是否可靠。演化型（演化型（evolutionaryprototyping）其目的是将原型作为目标系统的一部分，通过其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的对原型的多次改进，逐步将原型演化成最终的目
74、标系统。目标系统。原型的使用策略：原型的使用策略：废弃（废弃（throwaway）策略）策略主要用于探索型和实验型原型的开发。这些原型关注主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目索或实验的结果用良好的结构和设计思想重新设计目标系统。标系统。追加（追加（addon）策略）策
75、略主要用于演化型原型的开发。这种原型通常是实现了主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统。化成最终的目标系统。原型可作为单独的过程模型使用，它也常被作为一原型可作为单独的过程模型使用，它也常被作为一种方法或实现技术应用于其它的过程模型中。种方法或实现技术应用于其它的过程模型中。B.Boehm于于1988年提出年提出是瀑布模型和演化模型的结合，并增加了是瀑布模型和演化模型的结合，并增加了风风
76、险分析险分析螺旋模型沿着螺线旋转，在四个象限上分别螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：表达四个方面的活动，即：制定计划制定计划：确定软件目标，选定实施方案，：确定软件目标，选定实施方案，弄清项目开发的限制条件弄清项目开发的限制条件风险分析风险分析：评价所选的方案，识别风险，消：评价所选的方案，识别风险，消除风险除风险工程实施工程实施：实施软件开发，验证工作产品：实施软件开发，验证工作产品客户评估客户评估：评价开发工作，提出修正建议：评价开发工作，提出修正建议螺旋模型 螺旋模型出现了一些变种，它可以有螺旋模型出现了一些变种，它可以有3 3到到6 6个任务区域。个任务区域
77、。螺旋模型指引的软件项目开发沿着螺线螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本。出一个更为完善的新软件版本。如果发现风险太大，开发者和客户无法如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止。承受，则项目就可能因此而终止。多数情况下沿着螺线的活动会继续下去，多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望自内向外，逐步延伸，最终得到所期望的系统。的系统。喷泉模型喷泉模型是一种支持面向对象开发的模型体现迭代和无间隙特征迭代迭代：各开发活动常常重复工作多次，：各开发活动常常重复
78、工作多次，相关的功能在每次迭代中随之加入演进相关的功能在每次迭代中随之加入演进的系统的系统无间隙无间隙：开发活动之间不存在明显的边：开发活动之间不存在明显的边界界支持软件复用（reuse）利用预先包装好的软件构件（包括组织内部开发的构件和现存商品化构件COTS）来构造应用系统基于构件的开发模型领域分析领域分析构件可变性构件可变性分析分析构建构建可复用构件可复用构件领域模型领域模型领域基准领域基准体系结构图体系结构图可复用可复用构件库构件库分析分析体系结构设计体系结构设计获取构件获取构件构件特化构件特化和修改和修改评价评价构件组装构件组装和测试和测试开发未找到开发未找到构件的部分构件的部分应用系
79、统工程应用系统工程应用系统应用系统领域工程领域工程领域工程的目的是构建领域模型、领域领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。基准体系结构和可复用构件库。领域分析分析该领域中各种应用系统的领域分析分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和公共部分或相似部分，构建领域模型和领域基准体系结构（领域基准体系结构（referencearchitecture），标识领域的候选构件。），标识领域的候选构件。对候选构件进行可变性分析，以适应多对候选构件进行可变性分析，以适应多个应用系统的需要。个应用系统的需要。构建可复用构件，经严格测试和包装后构建可复用构件，经严格测试
80、和包装后存入可复用构件库（称为构件工程）。存入可复用构件库（称为构件工程）。应用系统工程的目的是使用可复用构件组装应应用系统工程的目的是使用可复用构件组装应用系统。用系统。分析待开发的应用系统，设计应用系统的体系结分析待开发的应用系统，设计应用系统的体系结构，标识应用系统所需的构件。构，标识应用系统所需的构件。在可复用构件库中查找合适的构件（也可购买第在可复用构件库中查找合适的构件（也可购买第三方的构件）。三方的构件）。特化选中的构件，必要时作适当的修改，以适应特化选中的构件，必要时作适当的修改，以适应该应用系统的需要。该应用系统的需要。开发那些未找到合适构件的应用部分。开发那些未找到合适构件
81、的应用部分。组装应用系统。组装应用系统。评价构件的复用情况，以改进可复用构件，同时评价构件的复用情况，以改进可复用构件，同时对新开发的部分进行评价，并向构件工程推荐候对新开发的部分进行评价，并向构件工程推荐候选构件。选构件。根据根据AT&T、Ericsson、HP公司的经验，公司的经验，有的软件复用率高达有的软件复用率高达90%以上，产品上以上，产品上市时间可缩短市时间可缩短25倍，错误率减少倍，错误率减少510倍，开发成本减少倍，开发成本减少15%75%。仅管这。仅管这些结论出自一些较好使用基于构件开发些结论出自一些较好使用基于构件开发的实例，但毫无疑问，基于构件的开发的实例，但毫无疑问，基
82、于构件的开发模型对提高软件生产率、提高软件质量、模型对提高软件生产率、提高软件质量、降低成本、提早上市时间起到很大的作降低成本、提早上市时间起到很大的作用。用。形式方法模型形式化方法（formal methods）是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求分析、规约、设计、编程、系统集成、测试、文档生成、直至维护各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的岐义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从
83、形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。净室过程模型系系统统工工程程需求需求收集收集代码代码审查审查盒结构盒结构规约规约形式化形式化设计设计正确性正确性验证验证代码代码生成生成统计统计使用使用测试测试认证认证测测 试试 计计 划划增量增量1 1需求需求收集收集代码代码审查审查盒结构盒结构规约规约形式化形式化设计设计正确性正确性验证验证代码代码生成生成统计使统计使用测试用测试认证认证测测 试试 计计 划划需求需求收集收集代码代码审查审查盒结构盒结构规约规约形式化形式化设计设计正确性正确性验证验证代码代码生成生成统计使统计使用测试用测试认证认证测测 试试 计计
84、 划划增量增量2 2增量增量3 3内容摘要计算机软件软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境敏捷软件开发软件开发的新挑战软件开发的新挑战快速的市场进入时间，要求高生产率快速的市场进入时间，要求高生产率快速变化的需求快速变化的需求快速发展的技术快速发展的技术传统的软件开发方法传统的软件开发方法强调过程强调过程强调文档强调文档开发人员负担过重开发人员负担过重称为重载称为重载(Heavyweight)方法方法针对上述问题，产生了一系列轻载针对上述问题，产生了一系列轻载(Lightweight)方法，如方法，如XP、SCRUM等。等。20012001年年2 2月，新方法的一些创始人在
85、美国犹月，新方法的一些创始人在美国犹他州成立了敏捷软件开发联盟他州成立了敏捷软件开发联盟 ，简称，简称Agile联盟。联盟。Agile联盟起草了一个敏捷软件开发宣言，联盟起草了一个敏捷软件开发宣言，该宣言由四个价值观声明组成，并提炼出敏该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的捷软件开发方法必须遵循的12条原则。条原则。Agile方法是在保证软件开发有成功产出的方法是在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品前提下，尽量减少开发过程中的活动和制品的方法。笼统的讲就是，的方法。笼统的讲就是，“刚刚好刚刚好”（Justenough），即开发中的活动及制品既
86、不要），即开发中的活动及制品既不要太多也不要太少。太多也不要太少。Agile方法的价值观个人和交互高于过程和工具 不是否定过程和工具的重要性，而是更强调软件开发中人的作用和交流的作用。 软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件。 如果光有定义良好的过程和先进的工具，而人员的技能很差，又不能很好地交流和协作，软件是很难成功地开发的。可运行软件高于详尽的文档可运行软件高于详尽的文档 通过执行一个可运行的软件来了解软件做了通过执行一个可运行的软件来了解软件做了什么，远比阅读厚厚的文档要容易得多。什么，远比阅读厚厚的文档要容易
87、得多。 敏捷软件开发强调不断地快速地向用户提交敏捷软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以可运行的软件（不一定是完整的软件），以得到用户的认可。得到用户的认可。 好的必要的文档仍是需要的，它能帮助我们好的必要的文档仍是需要的，它能帮助我们理解软件做什么，怎么做以及如何使用，但理解软件做什么，怎么做以及如何使用，但软件开发的主要目标是创建可运行的软件。软件开发的主要目标是创建可运行的软件。与客户协作高于合同（契约）谈判与客户协作高于合同（契约）谈判只有客户才能明确说明需要什么样的软件，只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户然而
88、，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变。早期确定的需求，以后也可能会改变。要想通过合同谈判的方式，将需求固定下来要想通过合同谈判的方式，将需求固定下来常常是困难的。常常是困难的。敏捷软件开发强调与客户的协作，通过与客敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现用户的需求。户的交流和紧密合作来发现用户的需求。对变更及时做出反应高于遵循计划对变更及时做出反应高于遵循计划任何软件项目的开发都应该制订一个项目计任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起
89、止日划，以确定各开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环期。然而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变。起止日期也可能因种种原因会改变。因此，项目计划应具有可塑性，有变动的余因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划地。当出现变化时及时做出反应，修订计划以适应变化。以适应变化。Agile方法的指导原则（1）最最优优先先的的是是通通过过尽尽早早地地和和不不断断地地提提交交有有价值的软件使客户满意价值的软件使客户满意（2）欢欢迎迎变变化化的的需
90、需求求，即即使使该该变变化化出出现现在在开开发发的的后后期期，为为了了提提升升对对客客户户的的竞竞争争优优势势，Agile过程利用变化作为动力过程利用变化作为动力（3）以以几几周周到到几几个个月月为为周周期期，尽尽快快、不不断断地地发布可运行软件发布可运行软件（4）在在整整个个项项目目过过程程中中，业业务务人人员员和和开开发发人人员必须天天一起工作员必须天天一起工作（5）以以积积极极向向上上的的员员工工为为中中心心建建立立项项目目组组，给给予予他他们们所所需需的的环环境境和和支支持持，对对他他们们的的工作予以充分的信任工作予以充分的信任（6）项项目目组组内内效效率率最最高高、最最有有效效的的信
91、信息息传传递递方式是面对面的交流方式是面对面的交流（7）测测量量项项目目进进展展的的首首要要依依据据是是可可运运行行的的软软件件（8）敏敏捷捷过过程程提提倡倡可可持持续续的的开开发发，项项目目发发起起者者、开开发发者者和和用用户户应应能能长长期期保保持持恒恒定定的的速度速度（9）应应时时刻刻关关注注技技术术上上的的精精益益求求精精和和好好的的设设计，以增强敏捷性计，以增强敏捷性（10）简简单单化化是是必必不不可可少少的的，这这是是尽尽可可能能减减少少不必要工作的艺术不必要工作的艺术（11）最最好好的的构构架架、需需求求和和设设计计出出自自于于自自我我组组织的团队织的团队（12）团团队队要要定定
92、期期反反思思怎怎样样才才能能更更有有效效，并并据据此调整自己的行为此调整自己的行为Agile方法的适用范围MartinFowler认为：新方法不是到处可适用的认为：新方法不是到处可适用的适合采用适合采用Agile方法的情况：方法的情况：需求不确定、易挥发（需求不确定、易挥发（Volatile,意指今天的意指今天的要求明天就不需要了）要求明天就不需要了）有责任感和积极向上的开发人员有责任感和积极向上的开发人员用户容易沟通并能参与用户容易沟通并能参与Agile的典型方法ExtremeProgramming(简称简称XP)SCRUMCrystalMethodologies(简称简称Crystal)F
93、eatureDrivenDevelopment(简称简称FDD)DynamicSystemsDevelopmentMethodology(简称简称DSDM)AdaptiveSoftwareDevelopment(简称简称ASD)PragmaticProgramming等等XP方法由Kent Beck提出，是Agile方法中最引人注目的一个XP最初实践于1997年Crysler公司的C3项目 (Smalltalk开发）适用于10人以下项目组、开发地点集中的场合 广泛用于需求模糊和挥发性强的场合IONA公司的Obix技术支持小组在采用了XP方法后，软件生产率提高了67%XP方法的4个价值观交流（交
94、流（Communication）实践表明，项目失败的重要原因之一是交流不实践表明，项目失败的重要原因之一是交流不畅，使得客户的需求不能准确地传递给开发人畅，使得客户的需求不能准确地传递给开发人员，造成开发人员不能充分理解需求；模型或员，造成开发人员不能充分理解需求；模型或设计的变动未能及时告知相关人员，造成系统设计的变动未能及时告知相关人员，造成系统的不一致和集成的困难的不一致和集成的困难所有项目相关人员之间充分的有效的交流是软所有项目相关人员之间充分的有效的交流是软件开发成功所必不可少的件开发成功所必不可少的XP方法提倡面对面的交流，这是一种有效的方法提倡面对面的交流，这是一种有效的也是效率
95、最高的交流方式也是效率最高的交流方式简单（简单（Simplicity）指在确保得到客户满意的软件的前提指在确保得到客户满意的软件的前提下，做最简洁的工作（简单的过程、下，做最简洁的工作（简单的过程、模型、文档、设计和实现）模型、文档、设计和实现）在开发中不断优化设计，时刻保持代在开发中不断优化设计，时刻保持代码简洁、无冗余码简洁、无冗余体现了敏捷开发的体现了敏捷开发的“刚刚好刚刚好(Justenough)”思想，即开发中的活动及制思想，即开发中的活动及制品既不要太多也不要太少，刚好即可品既不要太多也不要太少，刚好即可反馈（反馈（Feedback）及时有效的反馈能确定开发工作是否正确，及时有效的
96、反馈能确定开发工作是否正确，及时发现开发工作的偏差并加以纠正。及时发现开发工作的偏差并加以纠正。强调各种形式的反馈，如非正式的评审强调各种形式的反馈，如非正式的评审（走查，（走查，Walkthrough）、小发布等）、小发布等勇气（勇气（Courage） 采用敏捷软件开发需要勇气采用敏捷软件开发需要勇气：信任合作的同事，也相信自己信任合作的同事，也相信自己做能做到的最简单的事做能做到的最简单的事只有在绝对需要的时候才创建文档只有在绝对需要的时候才创建文档让业务人员制定业务决策，技术人员制定技术决策让业务人员制定业务决策，技术人员制定技术决策用可能的最简单的工具，例如白板和纸，只有在复杂建用可能
97、的最简单的工具，例如白板和纸，只有在复杂建模工具能提供可能的最好价值时才去使用它们模工具能提供可能的最好价值时才去使用它们相信程序员能制定设计决策，不需要给他们提供过多的相信程序员能制定设计决策，不需要给他们提供过多的细节细节需要勇气来承认自己是会犯错误的，需要勇气来相信自需要勇气来承认自己是会犯错误的，需要勇气来相信自己明天能克服明天出现的问题。己明天能克服明天出现的问题。XP方法的方法的12个核心实践个核心实践1.完整的团队（完整的团队（WholeTeam）所有的小组成员应在同一个工作地点工作所有的小组成员应在同一个工作地点工作成员中必须有一个现场用户（成员中必须有一个现场用户（On-si
98、teUser）由他提出需求，确定开发优先级由他提出需求，确定开发优先级通常还设一个通常还设一个“教练教练”（Coach）角色）角色教练指导教练指导XP方法的实施，以及与外部的沟方法的实施，以及与外部的沟通和协调通和协调2.计划对策（计划对策（PlanningGame）包括两类：发布计划和迭代（包括两类：发布计划和迭代（Iteration）计划）计划3.系统比喻系统比喻（Metaphor）系统比喻是待开发软件的一个每个成员都熟悉的系统比喻是待开发软件的一个每个成员都熟悉的形象化比喻，相当于一个粗略的软件体系结构形象化比喻，相当于一个粗略的软件体系结构4.小发布（小发布（Smallrelease）
99、经常、不断地发布可运行的、具有商业价值的小经常、不断地发布可运行的、具有商业价值的小软件版本，供现场用户评估或最终使用软件版本，供现场用户评估或最终使用5.测试（测试（testing）XP方法提倡测试优先，即先写测试后编代码方法提倡测试优先，即先写测试后编代码（testingthencoding）6.简单设计（简单设计（SimpleDesign）设计只考虑当前定义的功能而不考虑以后需求设计只考虑当前定义的功能而不考虑以后需求的变化的变化该设计是完成目前功能所需的最简洁的设计该设计是完成目前功能所需的最简洁的设计7.结对编程（结对编程（PairProgramming）一个程序员编程的同时，另一个
100、程序员负责检查一个程序员编程的同时，另一个程序员负责检查程序的正确性和可读性程序的正确性和可读性结对的伙伴结对的伙伴可以动态调整可以动态调整8.设计改进（设计改进（DesignImprovement）在不影响程序的外部可见行为的情况下，按高内在不影响程序的外部可见行为的情况下，按高内聚低耦合的原则对程序结构进行改进，保持代码聚低耦合的原则对程序结构进行改进，保持代码简洁、无冗余简洁、无冗余9.持续集成（持续集成（ContinuousIntegration）每完成一个模块的开发（包括该模块的单元测试）每完成一个模块的开发（包括该模块的单元测试）后，立即将其组装到系统中，并进行集成测试，后，立即将
101、其组装到系统中，并进行集成测试，完成该集成测试后才能进行下一次集成完成该集成测试后才能进行下一次集成10.代码全体共有（代码全体共有（CollectivecodeOwnership）团队中的任何人可以在任何时候修改系统任何位团队中的任何人可以在任何时候修改系统任何位置上的任何代码置上的任何代码团队的成员都可以参加模型的开发，又有系统比团队的成员都可以参加模型的开发，又有系统比喻、结对编程、编码标准、持续集成等实践，这喻、结对编程、编码标准、持续集成等实践，这些都为代码全体共有提供了支持些都为代码全体共有提供了支持11.编码标准（编码标准（CodingStandard）XP方法强调制订一个统一的
102、编码标准，包括命方法强调制订一个统一的编码标准，包括命名、注释、格式等编程风格名、注释、格式等编程风格12.可持续步调（可持续步调（SustainablePace）每周每周40小时工作制小时工作制XP方法的开发过程方法的开发过程最新版本最新版本发布计划发布计划 用户认可用户认可 用户用户 故事故事(user stories)下一迭代下一迭代Bugs新用户故事新用户故事测试用例测试用例迭代迭代开发开发体系结体系结构构骨骨架架(spike)系统比喻系统比喻制订交制订交付计划付计划验收验收测试测试小发布小发布需求需求不确不确定的定的估计估计确确定定的的估计估计难点难点骨架骨架探索阶段探索阶段计划阶段
103、计划阶段迭代与发布阶段迭代与发布阶段产品化阶段产品化阶段维护阶段维护阶段探索阶段探索阶段探索阶段的主要工作是开发初始的用户故事探索阶段的主要工作是开发初始的用户故事（UserStories）和体系结构骨架）和体系结构骨架（architecturespike）。）。用户故事描述了系统高层的需求，它是制订用户故事描述了系统高层的需求，它是制订发布计划的输入。发布计划的输入。在探索阶段，试探找到系统中固定不变的部在探索阶段，试探找到系统中固定不变的部分（体系结构骨架），并找出一种形象的比分（体系结构骨架），并找出一种形象的比喻，这种比喻描述了你打算如何构建系统，喻，这种比喻描述了你打算如何构建系统，
104、起到概念框架的作用。起到概念框架的作用。探索阶段还应根据用户故事编制相应的测试探索阶段还应根据用户故事编制相应的测试用例，供以后验收测试时使用。用例，供以后验收测试时使用。计划阶段计划阶段计划阶段的任务是根据用户故事描述的需求、计划阶段的任务是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计系统体系结构骨架和系统比喻来制订迭代计划和发布计划。划和发布计划。使用你最熟悉的形式为用户故事建模，这个使用你最熟悉的形式为用户故事建模，这个模型描述了用户故事的任务以及这些任务之模型描述了用户故事的任务以及这些任务之间的关系。间的关系。通常图形方式（可以是草图）比文字描述更通常图形方式（可以
105、是草图）比文字描述更直观。直观。尽可能精确地估算工作量，这是制订计划的尽可能精确地估算工作量，这是制订计划的重要依据。对于那些不能确切估算其工作量重要依据。对于那些不能确切估算其工作量的难点部分，要进一步作分析，直至能确定的难点部分，要进一步作分析，直至能确定其工作量估算。其工作量估算。迭代到发布阶段迭代到发布阶段迭代到发布阶段根据迭代和发布计划，开发迭代到发布阶段根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版完成的软件版本集成，得到软件的一个新版本。本。根据在探索阶段编写的测试用例，进行验收根据在探索
106、阶段编写的测试用例，进行验收测试。一旦发现错误或者通过验收测试想进测试。一旦发现错误或者通过验收测试想进入下一轮迭代时，就重复迭代开发的工作。入下一轮迭代时，就重复迭代开发的工作。在这一阶段当客户提出新的用户故事，或者在这一阶段当客户提出新的用户故事，或者根据项目的进展情况认为有必要时，可以回根据项目的进展情况认为有必要时，可以回到计划阶段，对迭代和发布计划做出修改或到计划阶段，对迭代和发布计划做出修改或调整。调整。产品化阶段产品化阶段产品化阶段的工作主要是确认迭代开发的软产品化阶段的工作主要是确认迭代开发的软件已经做好进入产品化的准备。件已经做好进入产品化的准备。在此阶段可进行更多的测试，如
107、系统测试、在此阶段可进行更多的测试，如系统测试、负载测试、安装测试等。负载测试、安装测试等。另一个工作就是整理文档。虽然敏捷软件开另一个工作就是整理文档。虽然敏捷软件开发的价值观中强调发的价值观中强调“可运行软件高于详尽的可运行软件高于详尽的文档文档”，但是，必要的文档仍是需要的。，但是，必要的文档仍是需要的。可能要写的文档：可能要写的文档：系统文档系统文档系统文档的目的在于为系统提供一个总览，来系统文档的目的在于为系统提供一个总览，来帮助人们理解它。主要包括：系统技术体系结帮助人们理解它。主要包括：系统技术体系结构和业务体系结构的总览、高层次的系统需求、构和业务体系结构的总览、高层次的系统需
108、求、关键设计决策的总结、体系结构图以及重要的关键设计决策的总结、体系结构图以及重要的设计模型（如果有的话）等。设计模型（如果有的话）等。操作文档操作文档操作文档的内容包括：系统涉及的依赖关系，操作文档的内容包括：系统涉及的依赖关系，与其他系统、数据库以及文件文互的特性，对与其他系统、数据库以及文件文互的特性，对备份流程的参考引用，系统的联系人列表以及备份流程的参考引用，系统的联系人列表以及联系方法，系统的适用性及可靠性需求的总结，联系方法，系统的适用性及可靠性需求的总结，系统预期负载情况概况，以及排错指导原则。系统预期负载情况概况，以及排错指导原则。支持文档支持文档支持支持文档的内容包括：支持
109、人员专用的培训教文档的内容包括：支持人员专用的培训教材，解决问题时作为参考的用户文档，排错指材，解决问题时作为参考的用户文档，排错指导原则，解决疑难问题时的上报流程，以及维导原则，解决疑难问题时的上报流程，以及维护团队的联系列表。护团队的联系列表。用户文档用户文档参考手册用于快速查询；用户指南用于指明系参考手册用于快速查询；用户指南用于指明系统的工作方式；支持指南用于指导如何获取其统的工作方式；支持指南用于指导如何获取其他的帮助；培训资料则主要用于培训。他的帮助；培训资料则主要用于培训。维护阶段维护阶段维护阶段涵盖了计划阶段、迭代到发布阶段维护阶段涵盖了计划阶段、迭代到发布阶段和产品化阶段和产
110、品化阶段通常这个阶段主要包括面向产品的活动，如通常这个阶段主要包括面向产品的活动，如系统的运行和支持。系统的运行和支持。内容摘要计算机软件软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境在软件工程活动中，软件工程师和管理人在软件工程活动中，软件工程师和管理人员按照软件工程的方法和原则，借助于计员按照软件工程的方法和原则，借助于计算机及其软件工具的帮助，开发、维护、算机及其软件工具的帮助，开发、维护、管理软件产品的过程称为计算机辅助软件管理软件产品的过程称为计算机辅助软件工程工程计算机辅助软件工程计算机辅助软件工程（CASE）ComputerAidedSoftwareEngineeri
111、ng软件工具软件工具是用来辅助计算机软件的开发、是用来辅助计算机软件的开发、运行、维护、管理、支持过程中的活动运行、维护、管理、支持过程中的活动或任务的软件或任务的软件按支持的软件过程活动分类：按支持的软件过程活动分类：开发过程：开发过程：需求分析工具，设计工具，编需求分析工具，设计工具，编码工具，测试工具码工具，测试工具它们还可按支持的开发方法分为：它们还可按支持的开发方法分为：结结构化构化XX工具工具，面向对象面向对象XX工具工具CASE工具工具维护过程：维护过程：版本控制工具，文档分析工具，版本控制工具，文档分析工具，逆向工程逆向工程（reverseengineering）工具，工具，再
112、工程再工程（reengineering）工具工具管理过程：管理过程：项目管理工具，配置管理工具，项目管理工具，配置管理工具，软件评价工具软件评价工具应用类工具应用类工具集成型开发环境是一种把支持集成型开发环境是一种把支持多种软件多种软件开发方法开发方法和和过程模型过程模型的软件工具集成到的软件工具集成到一起的软件开发环境一起的软件开发环境集成型开发环境由集成型开发环境由环境集成机制环境集成机制和和工具工具集集组成组成集成型软件开发环境集成型软件开发环境环境集成机制包括：环境集成机制包括：数据集成机制数据集成机制：为各种相互协作的工具：为各种相互协作的工具提供统一的数据接口规范提供统一的数据接口规范控制集成机制控制集成机制：支持各个工具或开发活：支持各个工具或开发活动之间的通信、切换、调度和协同工作，动之间的通信、切换、调度和协同工作，并支持软件开发过程的描述、执行与转并支持软件开发过程的描述、执行与转接接界面集成机制界面集成机制：支持工具界面的集成和：支持工具界面的集成和应用系统的界面开发，统一界面风格应用系统的界面开发，统一界面风格
