2009-7-26 1
软件工程
Software Engineering
主讲人 刘海岩
2009-7-26 2
参考文献
1,软件工程 — 实践者的研究方法
Roger S.Pressman (第 5版）
机械工业出版社
2,软件工程 — 理论与实践
Shari L.Pfleeger (第 2版）
高等教育出版社
3,软件工程（第 6版）
Ian Sommerville
机械工业出版社
2009-7-26 3
考核要求
1.笔试；
2.提交作业文档：
针对软件工程领域中的某个专题写出一篇论文。
论文要求,
（ 1）必须列出参考文献
（ 2）打印纸 4页以上
2009-7-26 4
第一章 绪论
软件工程产生的背景
软件工程的有关概念
软件生存周期及软件过程模型
软件开发方法
软件开发工具
2009-7-26 5
1.1 软件的特点、发展及软件危机
⒈ 软件的概念及其特点
◆软件是 ⑴当它被执行时提供希望功能和性能的程序,⑵使得程序能够适当的操作信息的 数据结构,
以及⑶描述程序被开发和运行过程中有关功能、结构、操作和使用的 文档 。
◆软件特征：
软件是逻辑的而不是有形的产品，它是被开发或设计出的，而非传统意义上的被制造的。软件成本和软件质量集中于开发上。
软件不会,磨损,。软件并不受到引起硬件磨损的环境因素的影响。
2009-7-26 6
2009-7-26 7
软件生产正走向基于构件的组装发展（如图形用户界面），但目前多数软件仍是定做的。
软件的研制需要投入大量的、复杂的脑力劳动，成本高。
⒉ 软件的发展
◆双重角色：
它是一个产品，通过计算机硬件所体现的计算潜能，它产生、管理、获取、修改、显示或传送信息，这些信息简单到一个 bit，复杂到一个多媒体信息；
它是产品交付使用的载体，是计算机控制的基础（操作系统）、信息通信的基础及其它软件的创建和控制的基础（软件工具和环境）。
2009-7-26 8
◆ 角色的演化：
早期（ 50年代初 -60年代中期）：
自定义软件
面向批处理第二阶段（ 60年代中期 -70年代末期）：
多用户
实时
数据库
软件产品软件危机出现！
2009-7-26 9
第三阶段（ 70年代中期 -80年代中期）：
分布式系统
嵌入式,智能,软件
低成本硬件
大众化第四阶段（ 80年代中期至今）：
强大的桌面系统
面向对象技术
人工智能
神经网络
并行计算
…
2009-7-26 10
3.软件危机 (crisis)
60年代中期，随着硬件技术的发展，软件应用范围的扩展，软件越来越大型化、复杂化，产生了上万行的源程序。
当发现错误是需要对这些程序进行修改；
当用户需求发生变化是需要修改；
当硬件环境更新时需要修改。
这些活动（称为软件维护）的 费用 以惊人的速度 增加 。
更糟糕的是，许多程序的个性化特性使得它们根本不能维护。,软件危机,出现了 !
2009-7-26 11
◆ 表现：
开发的软件不能满足用户要求。
无完整、规范的文档，难以维护。
项目计划不周，进度拖延。
软件质量差。
◆原因：
缺乏正确的理论指导，开发人员各行其是。
软件规模越来越大，无开发管理经验。
软件复杂度越来越高，而开发技术不相适应。
缺少先进的开发工具，开发方式落后。
2009-7-26 12
1.2 软件工程的有关概念为了克服软件危机，科学家们从其他产业 (如机械制造、建筑等）的工程化生产得到启示，于 1968年在北大西洋公约组织的学术会上提出了,软件工程,
的概念。 工程 是对技术（或社会）实体的分析、设计、
构造、验证和管理。这里只针对一个实体 — 计算机软件。
◆定义 根据 IEEE(The Institute for
Electrical and Electronic engineers)的定义：
软件工程 是使用系统化的、规范的、可量化的方法指导软件开发、运行和维护的一门学科，它涉及到计算机科学、工程科学、管理科学、数学等领域的综合性知识及实践的应用，它的目的是为建造高质量的软件提供一个框架 。
2009-7-26 13
◆ 软件工程层次图该图展现了软件工程研究的内容及关注的焦点。
2009-7-26 14
过程,定义了一系列活动,
技术方法的采用，
工程产品（模型、文档、数据）的产生，
里程碑（ milestone)的建立，
质量的保证及变化的管理。
该层构成了软件项目的管理控制的基础。
方法,提供了建造软件在技术上,如何做,。
方法覆盖了一系列任务：需求分析、设计、编程、
测试和支持（如纠错、适应、增强、预防）。
工具,对过程和方法提供了自动或半自动的支持。
2009-7-26 15
如果不考虑应用领域、项目规模和复杂性，与软件工程相关的工作可分为三个一般的阶段：
⑴ 定义阶段 集中于,做什么,。搞清楚要处理什么信息，预期完成什么功能和性能，系统将有什么样的行为，建立什么样的界面，有什么设计约束，以及建立一个成功系统的确认标准是什么。
⑵ 开发阶段 集中于,如何做,。即数据如何被结构化，功能如何被表示于软件体系结构中，过程细节及 界面如何实现，设计描述如何被翻译成程序语言，如何进新测试等活动。
⑶ 支持阶段 关注于,变化,。为纠正错误而做的修改，为适应环境的演化而做的修改，为增强用户的需求而做的修改以及使软件能被更好的维护而进行的软件再工程。
2009-7-26 16
软件通过应用这三个阶段实现工程化生产。
还有一些庇护性活动补充上述阶段的工作并贯穿于整个软件工程过程中，如：软件项目跟踪与控制、软件质量保证、软件配置管理等等。
◆能力成熟度模型 CMM
近年来,,过程成熟度,成为人们关注的焦点。美国 Carnegie-Meilon大学的软件工程研究所（ SEI）提出了一个综合模型，定义了当一个组织达到不同的过程成熟度时应该具有的软件工程能力。这个综合模型称为能力成熟度模型（ Capability Maturity Model,CMM)。
2009-7-26 17
该模型定义了 5个级别及每个级别上所需的关键活动：
⑴ 初始级 (initial),无严格定义的活动，项目的成功只依赖于关键人物的能力。
⑵ 可重复级（ repeatable),建立了基本的项目管理过程：需求管理、项目计划与跟踪、质量管理、配置管理、合同管理。有类似项目成功的案例和经验。
⑶ 已定义级（ defined),包含了第 2级的所有特征。
要求制定组织内部的工程化标准，包括管理和开发都需要一套文档化的标准，并集成到内部的软件过程中去。即所有项目都使用统一的、文档化的、组织过程认可的版本来开发和维护软件。
2009-7-26 18
⑷ 已管理级 (managed),包含了第 3级的所有特征。
该级的管理指量化的管理，即所有的过程需建立相应的度量方式，所有产品的质量要有明确的度量指标。
量化控制使软件开发真正变成工业生产活动。
⑸ 优化级 (optimizing),包含了第 4级的所有特征。
能根据反馈信息进行不断的过程改进，这些反馈信息来自于前期过程执行或试验新方法新技术而得到。 达到这一级表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程。
2009-7-26 19
CMM对软件企业有什么指导作用？
CMM建立了软件过程评价与改善及软件生产能力评估的基础，为软件企业提供一整套提高其软件生产能力的先进思路和方法，并通过评估使企业可对外证明其在软件产品提供方面具有的质量保证能力，受到全球各软件企业的重视和广泛采用并实施评估。
西安交大博通资讯股份有限公司于 2002年 12月获得 CMM3级认证。
CMM用于改进一个软件企业的管理能力。另外
TSP(Team Software Process）以提高一个开发团队的有效性； PSP（ Personal Software Process)则增强个人的技能与纪律。
2009-7-26 20
1.3 软件生存周期及软件过程模型软件生存周期是指一个软件从定义开始经过开发、
运行、维护，直到最后被废弃的全过程。引入此概念，
可以把软件生存周期划分为若干阶段。一般划分为：
软件定义,需求分析,软件设计,编码,测试及软件维护 等几个阶段。
每一阶段有明确的任务，把规模大、结构复杂、
管理复杂的软件开发变得容易控制和管理。
各个阶段的活动如何衔接，开发过程中采用什么样的策略，应遵守什么样的规定和制约，将这些活动框架（忽略不必要的细节）用一种模型表示出来，称为 软件过程模型 （或 软件开发模型 ）。
2009-7-26 21
软件过程模型的选择基于项目和应用的性质、采用的方法工具以及需要的控制和交付的产品。几种典型的模型：
⑴ 瀑布模型 (线性顺序模型）
2009-7-26 22
特点,
提供了软件过程模型的基本框架。
强调了每一阶段活动的严格顺序。
质量保证观点：以经过评审确认了的阶段工作产品（文档）驱动下一阶段的工作。
是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。
适合于用户需求明确、完整、无重大变化的软件项目开发。
2009-7-26 23
⑵ 原型模型在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，
快速建造一个原型（可运行的软件），然后进行评估，
进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。
2009-7-26 24
原型的分类：
抛弃型,主要用于需求分析阶段，针对开发目标模糊、用户与开发者对项目都缺乏经验的情况。建立原型的目的是为了搞清用户的需求，确定所期望的特性，探索各种方案的可行性。产生完整、一致、准确的需求说明。
实验型,主要用于设计阶段，通过原型验证设计方案的可行性。原型或成为设计结果的一部分或抛弃。
演化型,用于整个开发阶段。原型经过不断扩充，
演化为最终的软件系统。
2009-7-26 25
存在的问题,
⑴ 为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。
⑵ 为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。
⑶ 开发过程不便于管理。
有效的使用原型模式是,
建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。
2009-7-26 26
⑶ 增量模型是一种渐进地开发逐步完善的软件版本的模型。
2009-7-26 27
特点：
反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个,增量,的发布或提交，该增量均是一个可运行的产品。
早期的版本实现用户的基本需求，并提供给用户评估的平台。
⑷ 螺旋模型对于复杂的大型软件,开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了风险分析。在该模型中，软件开发使一系列的增量发布，早期的迭代中，发布的增量可能是一个纸上的模型或原型，在以后的迭代中，逐步产生系统更加完善的版本。
螺旋模型将开发过程划分为几个螺旋周期，每个周期有三到六个任务区域，见下图。
2009-7-26 28
2009-7-26 29
螺旋的第一圈可能产生产品的规格说明，再下面的螺旋可能用于开发一个原型，随后可能是软件的更完善的版本。每一圈还要根据用户评估的反馈对项目计划（包括进度、费用）进行调整。
特点,
适合于大型系统的软件开发，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险。
需要相当丰富的风险评估经验和专门知识，使该模型的应用受到一定限制。
随着迭代次数的增加，工作量加大，软件开发成本增加。
2009-7-26 30
⑸ 形式化方法模型是基于形式化语言和程序变换的模型，因此，也称变换模型。从软件需求形式化说明开始，经过一系列的数学变换和正确性证明，最终得到系统的目标程序。形式化方法使开发者应用一个严格的数学符号体系来表示、
构造和验证系统，从而大大提高软件的可靠性。
模型见下图：
2009-7-26 31
变换模型形式化规格说明与需求比较后修正形式化开发记录变换 n
变换 2
变换 1
测试系统需求 目标系统
…
2009-7-26 32
两种技术：
基于模型的规格说明及其变换技术基于模型的技术使用数学上的结构如集合和函数为系统建模。它们能展现系统的状态以简化对某些行为的描述。基于模型的描述语言及方法如 Z,VDM(Vienna
Definition Method),B,Petri Nets等。
基于代数结构及其变换技术代数方法适合于对接口的描述。这里接口被定义为一组对象类或抽象数据类型的集合，用接口操作之间的关系来刻画系统。
2009-7-26 33
特点,
该模型迫使对系统需求的分析在软件开发的早期阶段完成。在这个阶段改正错误比在系统被交付之后修改错误要经济得多。
形式化描述是对非形式化描述技术的补充。可以用来精化非形式化的详细的系统需求描述。描述是精确的和无二义的，避免了由于语言误解而产生的一些问题。
最适合用于安全性、可靠性和保密性等性能要求极高的系统。
开发成本较高。
需要严格的数学理论和开发环境的支持。
难以与用户进行通信。
2009-7-26 34
形式化过程模型的一个扩展，称为 净室软件工程
（ cleanroom software engineering)或 净室模型,它除了强调分析和设计上的严格性，以及使用基于数学的正确性证明来对设计模型的每个元素进行形式化验证外，还强调了统计质量控制技术。
基本思想,
力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或,洁净,的状态下实现软件的制作。
关键技术,
基于统计过程控制之下的增量开发
基于函数的规范、设计、验证
统计测试和软件认证模型见下图：
2009-7-26 35
净室模型盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #1
盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #2
盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #1
..
.
..
.
..
.
..
.
2009-7-26 36
⑹ 构件组装模型构件（ component)也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件组装起来协调工作。
该模型支持软件重用，对缩短软件开发周期、降低项目成本有重要的现实意义。同时，建造符合某应用领域体系结构标准的构件，可以用来搭建分布式的、
跨越不同操作平台的软件，扩展了软件的应用前景，
促进了软件标准化、商品化的发展。
因此，在此基础上专家们又提出了,基于构件的软件工程,(CBSE)。
构件组装模型如下图所示：
2009-7-26 37
构件组装模型
2009-7-26 38
软件体系结构被建立后，必须用构件去充实，这些构件可从复用库中获得，或者根据专门需要而开发。整个过程可以演化地进行，面向对象方法给予技术上的支持。
构件技术目前主要有三种流行标准：
OMG的 CORBA,对象管理组织发布的公共对象请求代理体系结构 (Common Object Request Broker
Architecture)。一个对象请求代理（ ORB)提供一系列服务，使得一个构件和其他构件通信，而不管它们在系统中的位置，实现了远程对象通过接口进行通信的机制。
2009-7-26 39
微软的 COM/DCOM：微软开发了构件对象模型
（ Component Object Model)，它提供了运行于 windows
之上的单个应用系统使用不同厂商生产的构件的规约。
基于分布式环境下的 COM称为 DCOM (Distribute COM)。
SUN的 EJB (Enterprise JavaBean)：随着 Java在企业级应用的地位日趋重要,Sun提出了一个统一的企业级
Java平台 — J2EE。在 J2EE中,EJB负责最核心的业务处理。它为服务器端的应用程序提供了一种与厂商无关的 Java接口，让任何符合 EJB规范的构件都可以运行在每一台这样的服务器上。
2009-7-26 40
⑺ 统一软件开发过程是由 Rational公司的 Booch,Jacobson,Rumbaugh
提出的软件过程模型，也称 RUP(Rational Unified
Process)。 RUP重复一系列周期，每个周期由一个交付给用户的产品结束。
每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流（需求、分析、
设计、实现、测试）分别迭代。
模型见下图：
2009-7-26 41
2009-7-26 42
初始阶段,进行问题定义，确定目标，评估其可行性，降低关键风险。
细化阶段,制定项目计划、配置各类资源、建立系统架构（包括各类视图）。
构造阶段,开发整个产品，并确保产品可移交给用户。
移交阶段,产品发布、安装、用户培训。
在每个阶段的每次迭代的最后，用例模型、分析模型、设计模型、实现模型都会增量，每个阶段结束的里程碑处，管理层做出是否继续、进度、预算、是否给下一阶段提供资助等决定。
不同阶段工作流的侧重点不同，前两阶段大部分工作集中在需求、分析和架构设计上；在构造阶段，重点转移到详细设计、实现和测试上。
2009-7-26 43
1.4 软件开发方法
1,结构化方法（ SA,SD,IDEF)
2,面向数据结构的方法（ Jackson,Warnier-On)
3,形式化开发方法（ VDM)
4,面向对象的开发方法
Coad-Yourdon,Booch,Rumbaugh,Jacobson
5,敏捷 （ agile)开发 方法极限编程 (Extreme Programming,XP)是其中的一种主要方法。支持需求变化、递增式开发。每一递增周期的代码必须充分测试（单元测试），用户和开发组在一起，随时保证做出的功能满足用户的需求，项目组成员在同一地点工作，保证高效的面对面交流，
要经常性的（如每个周期结束） 进行回顾，随时调整方法与过程以达到最有效的开发。
2009-7-26 44
1.5 软件开发工具软件开发工具对软件过程和方法提供了自动的或半自动的支持。
1,工具箱：各种工具的组合，界面不统一 。
2,软件开发环境：各阶段使用的软件工具集合成一个完整的整体，支持软件开发的全过程。如 Delphi。
3,计算机辅助软件工程 （ Computer Aided
Software Engineering,CASE)：方法与工具的结合，
支持某种方法论，支持某种过程模型，帮助软件开发人员进一步提高软件开发的效率和质量。 CASE可以简单到辅助某特定的软件工程活动（如分析建模），也可以复杂到一个完整的环境，它包含工具、数据库、
人员、硬件、网络、操作系统、标准及其它部件。
2009-7-26 45
CASE的构造积木块如图所示：
2009-7-26 46
⑴ 环境体系结构,由硬件平台和系统支持（包括网络软件、数据库管理和对象管理服务）构成，
是 CASE的基石。
⑵ 可移植服务,提供了工具及其集成框架与环境体系结构的桥梁，即允许工具及其集成框架能跨越不同硬件平台和操作系统使用，而不需要做大量的适应性修改。
⑶ 集成框架,是一组专用程序，它们使得个体的 CASE工具可以和其他工具相互通信，能够建立项目数据库，以及向开发人员展示相同的界面。
2009-7-26 47
集成框架有如下结构：
用户界面层：包含标准的界面工具箱和公共的表示协议（给予 CASE工具相同界面的一组指导原则：屏幕布局约定、菜单名和组织、图符、对象名、键盘和鼠标的使用以及工具访问机制等表示协议）。
工具管理层：协调工具的使用。
对象管理层：提供配置管理服务。
共享数据库层,完成对象管理层与数据库的访问控制。
⑷ 工具,项目管理工具、分析与设计工具、编程工具、测试工具、原型建造工具、界面开发工具、风险分析工具、文档工具以及再工程工具等。
软件工程
Software Engineering
主讲人 刘海岩
2009-7-26 2
参考文献
1,软件工程 — 实践者的研究方法
Roger S.Pressman (第 5版）
机械工业出版社
2,软件工程 — 理论与实践
Shari L.Pfleeger (第 2版）
高等教育出版社
3,软件工程（第 6版）
Ian Sommerville
机械工业出版社
2009-7-26 3
考核要求
1.笔试；
2.提交作业文档：
针对软件工程领域中的某个专题写出一篇论文。
论文要求,
（ 1）必须列出参考文献
（ 2）打印纸 4页以上
2009-7-26 4
第一章 绪论
软件工程产生的背景
软件工程的有关概念
软件生存周期及软件过程模型
软件开发方法
软件开发工具
2009-7-26 5
1.1 软件的特点、发展及软件危机
⒈ 软件的概念及其特点
◆软件是 ⑴当它被执行时提供希望功能和性能的程序,⑵使得程序能够适当的操作信息的 数据结构,
以及⑶描述程序被开发和运行过程中有关功能、结构、操作和使用的 文档 。
◆软件特征：
软件是逻辑的而不是有形的产品，它是被开发或设计出的，而非传统意义上的被制造的。软件成本和软件质量集中于开发上。
软件不会,磨损,。软件并不受到引起硬件磨损的环境因素的影响。
2009-7-26 6
2009-7-26 7
软件生产正走向基于构件的组装发展（如图形用户界面），但目前多数软件仍是定做的。
软件的研制需要投入大量的、复杂的脑力劳动，成本高。
⒉ 软件的发展
◆双重角色：
它是一个产品，通过计算机硬件所体现的计算潜能，它产生、管理、获取、修改、显示或传送信息，这些信息简单到一个 bit，复杂到一个多媒体信息；
它是产品交付使用的载体，是计算机控制的基础（操作系统）、信息通信的基础及其它软件的创建和控制的基础（软件工具和环境）。
2009-7-26 8
◆ 角色的演化：
早期（ 50年代初 -60年代中期）：
自定义软件
面向批处理第二阶段（ 60年代中期 -70年代末期）：
多用户
实时
数据库
软件产品软件危机出现！
2009-7-26 9
第三阶段（ 70年代中期 -80年代中期）：
分布式系统
嵌入式,智能,软件
低成本硬件
大众化第四阶段（ 80年代中期至今）：
强大的桌面系统
面向对象技术
人工智能
神经网络
并行计算
…
2009-7-26 10
3.软件危机 (crisis)
60年代中期，随着硬件技术的发展，软件应用范围的扩展，软件越来越大型化、复杂化，产生了上万行的源程序。
当发现错误是需要对这些程序进行修改；
当用户需求发生变化是需要修改；
当硬件环境更新时需要修改。
这些活动（称为软件维护）的 费用 以惊人的速度 增加 。
更糟糕的是，许多程序的个性化特性使得它们根本不能维护。,软件危机,出现了 !
2009-7-26 11
◆ 表现：
开发的软件不能满足用户要求。
无完整、规范的文档，难以维护。
项目计划不周，进度拖延。
软件质量差。
◆原因：
缺乏正确的理论指导，开发人员各行其是。
软件规模越来越大，无开发管理经验。
软件复杂度越来越高，而开发技术不相适应。
缺少先进的开发工具，开发方式落后。
2009-7-26 12
1.2 软件工程的有关概念为了克服软件危机，科学家们从其他产业 (如机械制造、建筑等）的工程化生产得到启示，于 1968年在北大西洋公约组织的学术会上提出了,软件工程,
的概念。 工程 是对技术（或社会）实体的分析、设计、
构造、验证和管理。这里只针对一个实体 — 计算机软件。
◆定义 根据 IEEE(The Institute for
Electrical and Electronic engineers)的定义：
软件工程 是使用系统化的、规范的、可量化的方法指导软件开发、运行和维护的一门学科，它涉及到计算机科学、工程科学、管理科学、数学等领域的综合性知识及实践的应用，它的目的是为建造高质量的软件提供一个框架 。
2009-7-26 13
◆ 软件工程层次图该图展现了软件工程研究的内容及关注的焦点。
2009-7-26 14
过程,定义了一系列活动,
技术方法的采用，
工程产品（模型、文档、数据）的产生，
里程碑（ milestone)的建立，
质量的保证及变化的管理。
该层构成了软件项目的管理控制的基础。
方法,提供了建造软件在技术上,如何做,。
方法覆盖了一系列任务：需求分析、设计、编程、
测试和支持（如纠错、适应、增强、预防）。
工具,对过程和方法提供了自动或半自动的支持。
2009-7-26 15
如果不考虑应用领域、项目规模和复杂性，与软件工程相关的工作可分为三个一般的阶段：
⑴ 定义阶段 集中于,做什么,。搞清楚要处理什么信息，预期完成什么功能和性能，系统将有什么样的行为，建立什么样的界面，有什么设计约束，以及建立一个成功系统的确认标准是什么。
⑵ 开发阶段 集中于,如何做,。即数据如何被结构化，功能如何被表示于软件体系结构中，过程细节及 界面如何实现，设计描述如何被翻译成程序语言，如何进新测试等活动。
⑶ 支持阶段 关注于,变化,。为纠正错误而做的修改，为适应环境的演化而做的修改，为增强用户的需求而做的修改以及使软件能被更好的维护而进行的软件再工程。
2009-7-26 16
软件通过应用这三个阶段实现工程化生产。
还有一些庇护性活动补充上述阶段的工作并贯穿于整个软件工程过程中，如：软件项目跟踪与控制、软件质量保证、软件配置管理等等。
◆能力成熟度模型 CMM
近年来,,过程成熟度,成为人们关注的焦点。美国 Carnegie-Meilon大学的软件工程研究所（ SEI）提出了一个综合模型，定义了当一个组织达到不同的过程成熟度时应该具有的软件工程能力。这个综合模型称为能力成熟度模型（ Capability Maturity Model,CMM)。
2009-7-26 17
该模型定义了 5个级别及每个级别上所需的关键活动：
⑴ 初始级 (initial),无严格定义的活动，项目的成功只依赖于关键人物的能力。
⑵ 可重复级（ repeatable),建立了基本的项目管理过程：需求管理、项目计划与跟踪、质量管理、配置管理、合同管理。有类似项目成功的案例和经验。
⑶ 已定义级（ defined),包含了第 2级的所有特征。
要求制定组织内部的工程化标准，包括管理和开发都需要一套文档化的标准，并集成到内部的软件过程中去。即所有项目都使用统一的、文档化的、组织过程认可的版本来开发和维护软件。
2009-7-26 18
⑷ 已管理级 (managed),包含了第 3级的所有特征。
该级的管理指量化的管理，即所有的过程需建立相应的度量方式，所有产品的质量要有明确的度量指标。
量化控制使软件开发真正变成工业生产活动。
⑸ 优化级 (optimizing),包含了第 4级的所有特征。
能根据反馈信息进行不断的过程改进，这些反馈信息来自于前期过程执行或试验新方法新技术而得到。 达到这一级表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程。
2009-7-26 19
CMM对软件企业有什么指导作用？
CMM建立了软件过程评价与改善及软件生产能力评估的基础，为软件企业提供一整套提高其软件生产能力的先进思路和方法，并通过评估使企业可对外证明其在软件产品提供方面具有的质量保证能力，受到全球各软件企业的重视和广泛采用并实施评估。
西安交大博通资讯股份有限公司于 2002年 12月获得 CMM3级认证。
CMM用于改进一个软件企业的管理能力。另外
TSP(Team Software Process）以提高一个开发团队的有效性； PSP（ Personal Software Process)则增强个人的技能与纪律。
2009-7-26 20
1.3 软件生存周期及软件过程模型软件生存周期是指一个软件从定义开始经过开发、
运行、维护，直到最后被废弃的全过程。引入此概念，
可以把软件生存周期划分为若干阶段。一般划分为：
软件定义,需求分析,软件设计,编码,测试及软件维护 等几个阶段。
每一阶段有明确的任务，把规模大、结构复杂、
管理复杂的软件开发变得容易控制和管理。
各个阶段的活动如何衔接，开发过程中采用什么样的策略，应遵守什么样的规定和制约，将这些活动框架（忽略不必要的细节）用一种模型表示出来，称为 软件过程模型 （或 软件开发模型 ）。
2009-7-26 21
软件过程模型的选择基于项目和应用的性质、采用的方法工具以及需要的控制和交付的产品。几种典型的模型：
⑴ 瀑布模型 (线性顺序模型）
2009-7-26 22
特点,
提供了软件过程模型的基本框架。
强调了每一阶段活动的严格顺序。
质量保证观点：以经过评审确认了的阶段工作产品（文档）驱动下一阶段的工作。
是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。
适合于用户需求明确、完整、无重大变化的软件项目开发。
2009-7-26 23
⑵ 原型模型在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，
快速建造一个原型（可运行的软件），然后进行评估，
进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。
2009-7-26 24
原型的分类：
抛弃型,主要用于需求分析阶段，针对开发目标模糊、用户与开发者对项目都缺乏经验的情况。建立原型的目的是为了搞清用户的需求，确定所期望的特性，探索各种方案的可行性。产生完整、一致、准确的需求说明。
实验型,主要用于设计阶段，通过原型验证设计方案的可行性。原型或成为设计结果的一部分或抛弃。
演化型,用于整个开发阶段。原型经过不断扩充，
演化为最终的软件系统。
2009-7-26 25
存在的问题,
⑴ 为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。
⑵ 为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。
⑶ 开发过程不便于管理。
有效的使用原型模式是,
建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。
2009-7-26 26
⑶ 增量模型是一种渐进地开发逐步完善的软件版本的模型。
2009-7-26 27
特点：
反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个,增量,的发布或提交，该增量均是一个可运行的产品。
早期的版本实现用户的基本需求，并提供给用户评估的平台。
⑷ 螺旋模型对于复杂的大型软件,开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了风险分析。在该模型中，软件开发使一系列的增量发布，早期的迭代中，发布的增量可能是一个纸上的模型或原型，在以后的迭代中，逐步产生系统更加完善的版本。
螺旋模型将开发过程划分为几个螺旋周期，每个周期有三到六个任务区域，见下图。
2009-7-26 28
2009-7-26 29
螺旋的第一圈可能产生产品的规格说明，再下面的螺旋可能用于开发一个原型，随后可能是软件的更完善的版本。每一圈还要根据用户评估的反馈对项目计划（包括进度、费用）进行调整。
特点,
适合于大型系统的软件开发，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险。
需要相当丰富的风险评估经验和专门知识，使该模型的应用受到一定限制。
随着迭代次数的增加，工作量加大，软件开发成本增加。
2009-7-26 30
⑸ 形式化方法模型是基于形式化语言和程序变换的模型，因此，也称变换模型。从软件需求形式化说明开始，经过一系列的数学变换和正确性证明，最终得到系统的目标程序。形式化方法使开发者应用一个严格的数学符号体系来表示、
构造和验证系统，从而大大提高软件的可靠性。
模型见下图：
2009-7-26 31
变换模型形式化规格说明与需求比较后修正形式化开发记录变换 n
变换 2
变换 1
测试系统需求 目标系统
…
2009-7-26 32
两种技术：
基于模型的规格说明及其变换技术基于模型的技术使用数学上的结构如集合和函数为系统建模。它们能展现系统的状态以简化对某些行为的描述。基于模型的描述语言及方法如 Z,VDM(Vienna
Definition Method),B,Petri Nets等。
基于代数结构及其变换技术代数方法适合于对接口的描述。这里接口被定义为一组对象类或抽象数据类型的集合，用接口操作之间的关系来刻画系统。
2009-7-26 33
特点,
该模型迫使对系统需求的分析在软件开发的早期阶段完成。在这个阶段改正错误比在系统被交付之后修改错误要经济得多。
形式化描述是对非形式化描述技术的补充。可以用来精化非形式化的详细的系统需求描述。描述是精确的和无二义的，避免了由于语言误解而产生的一些问题。
最适合用于安全性、可靠性和保密性等性能要求极高的系统。
开发成本较高。
需要严格的数学理论和开发环境的支持。
难以与用户进行通信。
2009-7-26 34
形式化过程模型的一个扩展，称为 净室软件工程
（ cleanroom software engineering)或 净室模型,它除了强调分析和设计上的严格性，以及使用基于数学的正确性证明来对设计模型的每个元素进行形式化验证外，还强调了统计质量控制技术。
基本思想,
力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或,洁净,的状态下实现软件的制作。
关键技术,
基于统计过程控制之下的增量开发
基于函数的规范、设计、验证
统计测试和软件认证模型见下图：
2009-7-26 35
净室模型盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #1
盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #2
盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #1
..
.
..
.
..
.
..
.
2009-7-26 36
⑹ 构件组装模型构件（ component)也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件组装起来协调工作。
该模型支持软件重用，对缩短软件开发周期、降低项目成本有重要的现实意义。同时，建造符合某应用领域体系结构标准的构件，可以用来搭建分布式的、
跨越不同操作平台的软件，扩展了软件的应用前景，
促进了软件标准化、商品化的发展。
因此，在此基础上专家们又提出了,基于构件的软件工程,(CBSE)。
构件组装模型如下图所示：
2009-7-26 37
构件组装模型
2009-7-26 38
软件体系结构被建立后，必须用构件去充实，这些构件可从复用库中获得，或者根据专门需要而开发。整个过程可以演化地进行，面向对象方法给予技术上的支持。
构件技术目前主要有三种流行标准：
OMG的 CORBA,对象管理组织发布的公共对象请求代理体系结构 (Common Object Request Broker
Architecture)。一个对象请求代理（ ORB)提供一系列服务，使得一个构件和其他构件通信，而不管它们在系统中的位置，实现了远程对象通过接口进行通信的机制。
2009-7-26 39
微软的 COM/DCOM：微软开发了构件对象模型
（ Component Object Model)，它提供了运行于 windows
之上的单个应用系统使用不同厂商生产的构件的规约。
基于分布式环境下的 COM称为 DCOM (Distribute COM)。
SUN的 EJB (Enterprise JavaBean)：随着 Java在企业级应用的地位日趋重要,Sun提出了一个统一的企业级
Java平台 — J2EE。在 J2EE中,EJB负责最核心的业务处理。它为服务器端的应用程序提供了一种与厂商无关的 Java接口，让任何符合 EJB规范的构件都可以运行在每一台这样的服务器上。
2009-7-26 40
⑺ 统一软件开发过程是由 Rational公司的 Booch,Jacobson,Rumbaugh
提出的软件过程模型，也称 RUP(Rational Unified
Process)。 RUP重复一系列周期，每个周期由一个交付给用户的产品结束。
每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流（需求、分析、
设计、实现、测试）分别迭代。
模型见下图：
2009-7-26 41
2009-7-26 42
初始阶段,进行问题定义，确定目标，评估其可行性，降低关键风险。
细化阶段,制定项目计划、配置各类资源、建立系统架构（包括各类视图）。
构造阶段,开发整个产品，并确保产品可移交给用户。
移交阶段,产品发布、安装、用户培训。
在每个阶段的每次迭代的最后，用例模型、分析模型、设计模型、实现模型都会增量，每个阶段结束的里程碑处，管理层做出是否继续、进度、预算、是否给下一阶段提供资助等决定。
不同阶段工作流的侧重点不同，前两阶段大部分工作集中在需求、分析和架构设计上；在构造阶段，重点转移到详细设计、实现和测试上。
2009-7-26 43
1.4 软件开发方法
1,结构化方法（ SA,SD,IDEF)
2,面向数据结构的方法（ Jackson,Warnier-On)
3,形式化开发方法（ VDM)
4,面向对象的开发方法
Coad-Yourdon,Booch,Rumbaugh,Jacobson
5,敏捷 （ agile)开发 方法极限编程 (Extreme Programming,XP)是其中的一种主要方法。支持需求变化、递增式开发。每一递增周期的代码必须充分测试（单元测试），用户和开发组在一起，随时保证做出的功能满足用户的需求，项目组成员在同一地点工作，保证高效的面对面交流，
要经常性的（如每个周期结束） 进行回顾，随时调整方法与过程以达到最有效的开发。
2009-7-26 44
1.5 软件开发工具软件开发工具对软件过程和方法提供了自动的或半自动的支持。
1,工具箱：各种工具的组合，界面不统一 。
2,软件开发环境：各阶段使用的软件工具集合成一个完整的整体，支持软件开发的全过程。如 Delphi。
3,计算机辅助软件工程 （ Computer Aided
Software Engineering,CASE)：方法与工具的结合，
支持某种方法论，支持某种过程模型，帮助软件开发人员进一步提高软件开发的效率和质量。 CASE可以简单到辅助某特定的软件工程活动（如分析建模），也可以复杂到一个完整的环境，它包含工具、数据库、
人员、硬件、网络、操作系统、标准及其它部件。
2009-7-26 45
CASE的构造积木块如图所示：
2009-7-26 46
⑴ 环境体系结构,由硬件平台和系统支持（包括网络软件、数据库管理和对象管理服务）构成，
是 CASE的基石。
⑵ 可移植服务,提供了工具及其集成框架与环境体系结构的桥梁，即允许工具及其集成框架能跨越不同硬件平台和操作系统使用，而不需要做大量的适应性修改。
⑶ 集成框架,是一组专用程序，它们使得个体的 CASE工具可以和其他工具相互通信，能够建立项目数据库，以及向开发人员展示相同的界面。
2009-7-26 47
集成框架有如下结构：
用户界面层：包含标准的界面工具箱和公共的表示协议（给予 CASE工具相同界面的一组指导原则：屏幕布局约定、菜单名和组织、图符、对象名、键盘和鼠标的使用以及工具访问机制等表示协议）。
工具管理层：协调工具的使用。
对象管理层：提供配置管理服务。
共享数据库层,完成对象管理层与数据库的访问控制。
⑷ 工具,项目管理工具、分析与设计工具、编程工具、测试工具、原型建造工具、界面开发工具、风险分析工具、文档工具以及再工程工具等。
