文章目录
软件工程第二章 软件生存周期与软件过程==2.1 软件生存周期==2.2 传统软件过程1.瀑布模型2.快速原型模型3.软件演化模型4.形式化方法模型5.净室模型 2.3 面向对象的模型1.喷泉模型2.构件集成模型3.面向Agent的软件工程 2.4 敏捷方法2.5 软件项目计划问题定义可行性研究软件风险分析项目实施计划软件工程
第二章 软件生存周期与软件过程
传统开发模型：瀑布模型、快速原型模型。
演化开发模型：增量模型、螺旋模型。
面向对象开发模型：喷泉模型、构件集成模型。
形式化开发模型：转换模型、净室模型。
2.1 软件生存周期
计划时期：
问题定性：系统解决什么问题、目标、范围。可行性分析：了解用户要求及观察环境、收集资料、数据流程、技术、经济、操作可行性、组织、人力、物力、效益。
开发时期：
运行时期需求分析：弄清用户的全部需求，用“需求规格说明书”准确地表达出来。软件设计：分为概要设计与详细设计，产生软件结构、数据结构、用户界面和算法、建立系统物理模型编码：实现用户界面，将详细设计“翻译”成程序代码。测试：单元、组装、确认、系统、白盒、黑盒。
软件运行与维护
程序维护 正确性维护：改正在开发阶段产生，在测试阶段又没有发现的错误。适应性维护：为适应软件的外界环境的变化引起的软件修改。完善性维护：为扩充软件系统功能或改善性能而进行的修改。 使用维护 环境维护：为保证软件产品正常运行而进行的维护（如主机、打印机等）。意外事故维护：解决因发生意外事故而使数据混乱或丢失的问题而进行的维护。计算机病毒治理和维护：预防、检测，清楚计算机病毒。
2.2 传统软件过程
1.瀑布模型
将软件生存周期各项活动规定位依线性顺序联结的若干阶段的模型。它包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序。
瀑布模型法适合于在软件需求比较明确、开发技术比较成熟、工程管理比较严格的场合下使用。
特点：
阶段的顺序性和依赖性推迟实现的挂点质量保证
存在问题：不适合需求模糊的系统。（在实际开发过程中，为了保证软件产品的质量，每个阶段完成之后，要对其阶段的工作和成果做出客观评价，如发现问题，就应停止前行，沿着所经历的阶段返回）
系统分析阶段的常用技术：
结构化系统分析方法（SA）结构化系统设计方法（SD）
系统分析阶段的软件工具：
信息关联图（IRD）管理业务流程图（TFD）数据流程图（DFD）数据词典（DD）实体-关系图（E-R）
系统设计阶段的软件工具：
系统模块结构图。Jackson设计方法。
程序设计阶段：
结构化程序设计方法（SP）
2.快速原型模型
从获得用户基本需求说明的基础上，投入少量人力和物力，快速建立一个原始模型，使用户及时运行和看到模型的概貌和使用效果，并对需求说明进行补充和精化，提出改进意见，开发人员进一步修改完善，如此循环迭代，知道得到一个用户满意的模型为止。
从原型法的基本思想中可以看到，用户能及早看到系统模型，在循环迭代修改和完善过程中，使用户的需求日益明确，从而消除了用户需求的不确定性，同时从原型到模型的生成，周期短、见效快，对环境变化的适应能力强。
（1）功能选择
最终系统是软件需求全部功能的实现，而原型只实现所选择的部分功能。最终系统对每个软件需求都要求详细实现，而原型仅仅是为了实验和演示，部分功能需求可以忽略，或者模拟实现。
（2）构造原型
根据用户初步需求，开发出一个可以应用的系统，它应满足上述的由用户提出的基本要求。在构造一个原型时，应当强调着眼于预期的评估，而不是为了正规的长期使用。
（3）运行和评价原型
在试用中能亲自参加和面对一个实在的模型，能较为直观和明确地进一步提出需求，提出修改意见。通过运行原型对软件需求规格说明进行评价和确认。评价要有用户参与，注意来自用户的反馈信息。
（4）修改和完善原型
根据修改意见进行修改，以得到新的系统原型，然后再进行试用和评价，这样经过有限次的循环反复，逐步提高和完善，知道得到一个用户满意的系统模型为止。根据原型实现的特点和环境，可以把原型作为实验的工具，用完就丢弃；也可以使原型全部或部分地称为最终系统的组成部分。
特点：
快速开发工具循环低成本
种类：
渐进型抛弃型
3.软件演化模型
阶段式开发：增量模型系统设计时分片交付，可使用户在使用某些基本功能的同时，开发剩余的功能。这样通常会并行地存在两个系统：生产系统和开发系统。运行或生产系统是当前被客户或用户所使用的系统。而开发系统是准备用于替代当前生产系统的下一个版本。
增量模型是一种非整体开发的模型。是瀑布模型的顺序特征和快速原型模型的迭代特征相结合的产物。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
增量：小而可用的软件。
特点：在前面增量的基础上开发后面的增量，每个增量的开发可用瀑布或快速原型模型迭代的思路。
螺旋模型
其基本思想是使用原型及其他方法以尽可能地降低风险。理解这种模型的简易方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。
每个阶段开始时的任务是，确定该阶段的目标、为完成这些目标选择方案及设定这些方案的约束条件。接下来的任务是，从风险角度分析上一步的工作结果。努力排除各种潜在的风险，通常用建造原型的方法来排除风险。如果风险不能排除，则停止开发工作或大幅度地削减项目规模。如果成功地排除了所有风险，则启动下一个开发步骤，在这个步骤的工作过程相当于纯粹的瀑布模型。最后是评价该阶段的工作成果并计划下一个阶段的工作。
螺旋模型将瀑布模型与增量模型结合起来，加入了两种模型均忽略了风险分析，弥补了这两种模型的不足。螺旋模型是一种风险驱动的模型。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。螺旋模型适合于大型软件的开发。
特点：瀑布模型+快速原型+风险分析
迭代过程：一个螺旋式周期。
4.形式化方法模型
形式化方法模型是一种基于数学的开发技术，主要采用数学的方法与表示体系描述软件的性质，表示软件规格说明，然后进行一系列自动或半自动的程序转换，最后转换为计算机系统能够接受的目标程序系统。
是基于形式化语言和程序变换的模型，因此也称为变换模型。从软件需求形式化说明开始，经过一系列的数学变换和正确性证明，最终得到系统的目标程序。形式化方法使开发者应用一个严格的数学符号体系来表示、构造和验证系统，从而大大提高软件的可靠性。
两种技术：
基于模型的规格说明及其变换技术：基于模型的技术使用数学上的结构如符合和函数为系统建模。它们能展现系统的状态以简化对某些行为的描述。基于代数结构及其变换技术：代数方法适合于对接口的描述。这里接口被定义为一组对象类或抽象数据类型的集合，用接口操作之间的关系来刻画系统。
特点：
该模型迫使对系统需求的分析在软件开发的早期阶段完成。在这个阶段改正错误比在系统被较复之后修改错误要经济得多。形式化描述是对形式化描述技术的补充。可以用来精化非形式化的详细的系统需求描述。描述是精确的和无二义的，避免了由于语言误解而产生的一些问题。最适合用于安全性、可靠性和保密性等性能要求极高的系统。开发成本较高。需要严格的数学理论和开发环境的支持。难以与用户进行通信。
5.净室模型
形式化过程模型的一个扩展，称为净室软件工程或净室模型，它除了强调分析和设计上的严格性，以及使用基于数学的正确性证明来对设计模型的每个元素进行形式化验证外，还强调了统计质量控制技术。其基本思想是：力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。
关键技术：
基于统计过程控制之下的增量开发。基于函数的规范、设计、验证。统计测试和软件认证。
形式化：
盒结构表示分析和设计正确性验证
2.3 面向对象的模型
1.喷泉模型
喷泉模型是属于面向对象方法学的，是一种以用户需求为动力，以对象作为驱动的模型。它适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。系统某些部分常常重复工作多次，相关功能在每次迭代中随之加入演化的系统。无间隙是指在分析、设计和实现等开发活动之间不存在明显的边界。特点：
开发过程有分析、系统设计、软件设计和实现4个阶段。各阶段相互重叠，它反映了软件过程并行性的特点。以分析为基础，资源消耗呈塔型。反映了软件过程迭代性的自然特性，从高层返回低层无资源消耗。强调增量开发，整个过程是一个迭代的逐步提炼的过程。喷泉模型是对象驱动的过程，对象是所有活动作用的实体，也是项目管理的基本内容。
2.构件集成模型
构件也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件组装起来协调工作。该模型支持软件重用，对缩短软件开发周期、降低项目成本有重要的现实意义。同时，建造符合某应用领域体系结构标准的构件，可以用来搭建分布式的、跨越不同操作平台的软件，扩展了软件的应用前景，促进了软件标准化、商品化的发展。特点：
面向对象基于构件库融合螺旋模型特征支持软件开发的迭代方法软件重用
构建技术目前的三种流行标准：
OMG的CORBA：对象管理组织发布的公共对象请求代理体系结构。一个对象请求代理（ORB）提供一系列服务，使得一个构件和其他构件通信，而不管它们在系统中的位置，实现了远程对象通过接口进行通信的机制。微软的COM/DCOM：微软开发了构件对象墨香，它提供了运行于windows之上的单个应用系统使用不同厂商生产的构件的规约。基于分布式环境下的COM称为DCOM。SUN的EJB：Sun提出了一个统一的企业级Java平台——J2EE。在J2EE中，EJB负责最核心的业务处理。它为服务器端的应用程序提供了一种于与厂商无关的Java接口，让任何符合EJB规范的构件都可以运行在每一台这样的服务器上。
基于构件的未来软件生产线：
应用构建提取车间-》应用构件库-》构建生产车间（基础构建、功能构件、接口构件、用户界面构件）-》构件库-》组装车间-》应用系统
3.面向Agent的软件工程
自主性Agent应是具有自身计算功能的自动控制行为的实体。它能够在非选定的模式下和动态变化的环境中，不用外界直接操纵，根据其内部状态和感知到的环境信息，决定和控制自身的行为。这是Agent区别于“对象”的一个重要特征。
Agent具有以下特点：
协作性：每个Agent是Agent社会的成员。它可以拥有其他的，包括人在内的Agent的信息和知识，并通过某种Agent通信语言与其他Agent进行交互、协同和合作。智能性：Agent应当包括了解、记录和执行“感知——推理——动作”的操作。例如，Agent可以记录用户的兴趣、推理用户的意图、克服遇到的困难。代理性：Agent代表用户进行工作，代替用户对各种资源的访问、分析和筛选，直到得到满意的结果。交互性：Agent（包括人）之间，用Agent通信语言事实灵活多样的交互。反应性：Agent能感知外部环境，并对相关的事物做出适时反应。主动性：Agent能够感知外界的环境，并对相关事物做出适时反应。机动性：灵活的访问各种资源、寻求服务。自成长性：Agent应该通过不断的实践，丰富和提高自己的知识，积累各种经验，为今后解决更复杂的问题选择捷径。
Agent与对象（Object）的区别：
对象封装了状态和行为的实现，没有封装行为的选择，一般是被动的存在，需要发送给它消息后才活动，而Agent是主动的。对象描述的行为粒度太细，对象之间的交互机制较简单。而Agent用其粗粒度和高级交互来描述系统的行为。对象之间的通信是通过直接调用方法来实现的，对于语法级。Agent之间的通信处于知识级。通过通信原语来实现。Agent之间的通信有专用的语言。如KQML。对象之间有继承关系，而Agent之间可有多种组织关系。Agent实现时一般是一个特殊的程序，而对象是一个类的实例。
面向Agent的高层建模：
Gaia建模方法多Agent系统的建模方法信息系统的建模
面向对象方法在AOSE中的应用
AUML（Agent UML）设计模式组件
2.4 敏捷方法
1.XP（Extreme Programming，极端编程方法）
2.Cockburn的水晶系列方法
3.ASD（Adaptive Software Development，自适应软件开发）方法
4.SCRUM方法
5.FDD（Feature-Driven Development 方法）
极限编程爱好者和敏捷方法一般将不断变化的需求看作是一个自然、不可避免、理想的软件开发项目的一个方面。他们认为在项目中任何时候适应不断变化的需求是一种更为现实和更好的方法，而不是在一个项目开始时试图确定所有需求、付出努力控制变化。
2.5 软件项目计划
问题定义
目的：
弄清需要解决的问题项目所需的资源和经费
任务：编写“系统目标与范围的说明”
可行性研究
目的：研究项目是否可能实现和值得进行（用最小的代价，在尽可能短的时间内确定）
研究的内容：
经济可行性 系统成本主要包括： 开发成本运行维护成本 系统效益包括： 经济效益社会效益 技术可行性 风险分析资源分析技术分析（现有技术能否实现新系统、技术难点） 运行可行性 组织上、人员上、设备上去研究确定并论证新系统的可行性，包括管理工作的规范性、科学性、信息的可靠性、管理水平、人员对新开发系统的设想和要求，现有人员对计算机知识的掌握程度是否足以支撑新系统的运行等。 法律可行性 研究在系统开发过程中可能涉及的人力资源、各种合同、知识产权纠纷、责任以及各种与法律、法规、政策和社会环境（含政治环境）相抵触的问题。
研究的步骤：
细化和修改“系统目标和范围”，得出新系统的逻辑模型导出新系统的解决方案提出推荐的方案
系统流程图：
描述系统物理模型包含人员、硬件、软件等子系统在黑盒级上描绘系统内部的主要成分，表达信息在各成分之间流动的情况系统流程图表达的是信息在系统各部件之间流动的情况，而不是对信息进行加工处理的控制过程，因此尽管系统流程图使用的某些符号和程序流程图中用的符号相同，但是它缺是物理数据流图而不是程序流程图。
软件风险分析
尽可能的量化不确定性的程度及每个风险导致的损失的程度，为软件开发的实施计划提供参考。
风险识别：
可用不同的方法对风险进行分类。从宏观上看，可将风险分为项目风险、技术风险和商业风险。
项目风险：识别潜在的预算、进度、个人（组织）、资源、用户和需求方面的问题，以及它们对软件项目的影响。如项目复杂性、规模和结构等都可构成风险因素。技术风险：识别潜在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。技术风险之所以出现是由于问题的解决比所预想的要复杂。商业风险：(1)建立的软件虽然很优秀但不是真正所想要的；(2)建立的软件不适合整个软件产品战略；(3)销售部门不清楚如何推销这种软件；(4)由于课题改变或人员而失去上级管理部门的支持；(5)失去预算或人员的承诺（预算风险）。
风险预测：
风险发生的可能性风险发生后所产生的后果
通常，项目计划人员与管理人员、技术人员一起，进行两项风险估计活动：
建立一个尺度或标准来表示一个风险的可能性 尺度可以用布尔值，定性的或定量的方式定义。一种比较好的方法是使用定量的概率尺度，它具有下列的值：极罕见的、罕见的、普通的、可能的、极可能的。 估计风险对项目和产品的影响风险发生的后果通常使用定性的描述：灾难性的、严重的、轻微的或可忽略的等等。造成影响的因素有三种：风险的性质、风险的范围和风险的实践。风险的性质指出在风险出现时可能出现的问题。例如，一个定义得很差的用户硬件的外部接口（技术风险）会妨碍早期的设计和测试，而且很可能在项目后期造成系统组装上的问题。风险的范围则组合了风险的严重性（即它严重到什么程度）与其总的分布（即对项目的影响有多大，对用户的损害又有多大）。风险的时间则考虑从风险的影响从什么时候开始，要影响多长时间。在多数情况下，项目管理人员可能希望“坏消息”出现得越早越好，但在有些情况下则拖得比较长。
在风险分析过程中进行风险评价得时候，应当建立一个三元组：[ri, li, xi]
其中，ri是风险、li是风险出现的可能性、xi是风险的影响。在做风险评价时，应当进一步检验在风险估计时所得到的估计的准确性，尝试对已暴露的风险进行优先排队，并着手考虑控制或消除可能出现风险的方法。
在做风险评价时，按以下步骤执行：
为项目定义风险参照水准；尝试找出在每个[ri, li, xi]和每个参照水准之间的关系；预测参照点组成定义一个终止区域，用一条曲线或一些易变动区域来界定；努力预测复合的风险组合将如何形成一个参照水准。
风险的驾驭和监控：
风险驾驭是指利用某些技术，如原型话、软件自动化、软件心理学、可靠性工程学以及某些项目管理方法等设法避开或转移风险。与每一风险相关的三元组（风险描述，风险可能性，风险影响）是建立风险驾驭（风险消除）步骤的基础。风险缓解、监控和管理计划（RMMMP）记叙了风险分析的全部工作，并且作为整个项目计划的一部分为项目管理人员所使用。驾驭风险的措施会增加项目成本，称之为风险成本。
常见的软件系统风险：后门/陷阱门、人为错误、拒绝使用、辐射、盗用、无法使用、火灾和自然灾害、伪造、硬件故障、假冒、不准确的或过时的信息、故意对数据或程序进行破坏、逻辑炸弹、错误传递、程序编制错误、破坏活动、废物利用、超级处理、偷窃行为、计算机病毒。
