搜索
第四章软件工程2019/8/91本章学习的主要内容第1节软件工程概述第2节软件开发模型第3节软件需求分析第4节软件设计概述第5节项目开发过程2019/8/92第1节软件工程概述软件与软件危机软件工程学传统软件工程和面向对象软件工程2019/8/93软件程序、软件与软件产品独唱--小合唱--合唱--万人大合唱|||简单程序较复杂程序软件软件定义：软件=程序+数据+文档程序：按事先设计的功能和性能需求执行的指令序列数据：是程序能正常操纵信息的数据结构文档：与程序开发、维护和使用有关的图文材料2019/8/94软件开发的发展过程程序设计时代（1946-1955）硬件配置低，内存小速度慢，稳定性差程序以机器语言、汇编语言；程序规模小，结构简单软件时代（1955-1970）计算机性能提高，产量上升提出软件的概念，软件需求猛增，开发技术能力不足软件工程时代（1970-今）硬件已不是考虑的问题对开发方法、技术理论进行研究2019/8/95软件开发的发展过程计算机应用发展软件数量多规模大软件成本高质量低个体化软件开发方法软件维护困难软件危机软件工程2019/8/96软件工程时代第一代软件技术自顶向下、逐步求精的结构化程序设计方法第二代软件技术软件生存周期，注重软件测试技术第三代软件技术需求分析方法高层定义低层实施2019/8/97软件危机定义计算机软件的开发和维护过程所遇到的一系列严重问题表现对软件开发成本和进度的估算很不准确用户很不满意质量很不可靠没有适当的文档软件成本比重上升供不应求：软件开发生产率跟不上计算机应用迅速深入的趋势2019/8/98硬件/软件成本变化趋势硬件软件100%0%1955197019852019/8/99软件技术进步落后于需求增长2019/8/910软件危机原因客观：软件本身特点逻辑部件规模庞大主观：不正确的开发方法忽视需求分析错误认为：软件开发=程序编写轻视软件维护2019/8/911软件危机解决途径组织管理工程项目管理方法技术措施软件开发技术与方法软件工具2019/8/912软件工程学的范畴软件工程学指导计算机软件开发和维护的工程学科工程管理+开发技术软件开发技术软件开发方法学软件工具软件工程管理软件管理学软件经济学软件度量学2019/8/913两种程序设计方法程序设计的两次飞跃结构化程序设计程序=数据结构+算法面向对象程序设计程序=对象+消息2019/8/914面向过程和面向对象的编码存款取款利息结算帐户余额帐户余额利息结算存款取款2019/8/915两类软件工程方法传统软件工程软件分析→总体设计→详细设计→面向过程的编码→测试面向对象软件工程软件分析与对象抽取→对象详细设计→面向对象的编码→测试2019/8/916软件工程的目的适用性有效性可修改性可靠性可理解性可维护性可重用性可移植性可追踪性可互操作性2019/8/917第2节软件开发模型传统开发模型瀑布模型（waterfallmodel）快速原型模型（rapidprototypemodel）演化开发模型增量模型（incrementalmodel）螺旋模型（spiralmodel）面向对象开发模型构件集成模型（componentintegrationmodel）形式化开发模型转换模型（transformationalmodel）净室模型（cleanroommodel）2019/8/918瀑布生存周期模型计划时期问题定义可行性分析开发时期需求分析软件设计编码测试运行时期软件维护2019/8/919瀑布模型问题定义可行性研究需求分析软件设计编码测试维护计划时期开发时期运行时期2019/8/920瀑布模型特点阶段的顺序性和依赖性（故也称线性顺序模型）推迟实现原则（宁慢求好）质量保证存在问题不适合需求模糊的系统2019/8/921瀑布模型1、瀑布模型有以下优点1）为项目提供了按阶段划分的检查点。2）当前一阶段完成后，只需要去关注后续阶段。3）可在迭代模型中应用瀑布模型。2、瀑布模型有以下缺点1）在项目各个阶段之间极少有反馈。2）只有在项目生命周期的后期才能看到结果。3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。2019/8/922快速原型模型原型是指模拟某种产品的原始模型。快速原型模型需要迅速建造一个可以运行的软件原型；便于理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。2019/8/923快速原型模型需求分析原型开发最终系统设计原型评价最终系统实现用户反馈2019/8/924快速原型模型特点需要快速开发工具支持循环开发模式适用于用户需求不明确的情况种类渐进型抛弃型2019/8/925增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。2019/8/926增量模型规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户增量1增量2增量3增量n2019/8/927增量模型增量小而可用的软件特点在前面增量的基础上开发后面的增量每个增量的开发可用瀑布或快速原型模型迭代的思路2019/8/928增量模型优点人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。可先发布部分功能给客户，对客户起到镇静剂的作用。增量能够有计划地管理技术风险。缺点1）需要软件具备开放式的体系结构。2）容易退化为边做边改模型，从而是软件过程的控制失去整体性。3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析。2019/8/929螺旋模型2019/8/930将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。螺旋模型沿螺线进行若干次迭代，将工程分为四个活动：（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；（3）实施工程：实施软件开发和验证；（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。螺旋模型2019/8/931螺旋模型特点瀑布模型+快速原型+风险分析迭代过程一个螺旋式周期确定目标，选择方案，选定完成目标的策略风险角度分析该策略启动一个开发阶段评价前一步的结果，计划下一轮的工作螺旋模型的项目适用：对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！2019/8/932螺旋模型优点1）设计上的灵活性，可以在项目的各个阶段进行变更。2）以小的分段来构建大型系统，使成本计算变得简单容易。3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性。4）随着项目推进，客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。缺点很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。2019/8/933面向对象模型对象Object类Class继承Inheritance消息Message面向对象对象+类+继承+消息通信2019/8/934构件集成模型构件集成模型利用预先封装好的软件构件来构造应用软件系统，它融合了螺旋模型的很多特征，支持软件开发的迭代方法。开发活动从描述候选类开始，通过检查软件系统处理的数据以及操作这些数据的方法，把相关的数据和方法封装成一个类，然后到构件库中查找这个类。如果已经存在，就从库中提取出来以供复用；如果候选类不存在，则采用面向对象的方法使它实现，并把它存储到构件库中。通过集成从构件库中提取的已有类和为了满足应用程序的特定需要而构建的新类，即可得到待开发软件的第一个迭代。然后进入下一轮螺旋周期，继续进行构件集成的迭代。2019/8/935构件集成模型2019/8/936构件集成模型特点面向对象基于构件库融合螺旋模型特征支持软件开发的迭代方法软件重用2019/8/937转换模型该模型结合了形式化软件开发方法和程序自动生成技术，采用形式化需求规格说明和变换技术等技术手段，生产目标程序系统。软件需求分析确定以后，选用某种形式化的需求规格说明语言描述软件规格说明，可以生成形式化的规格说明。为了确认该形式化规格说明与软件需求的一致性，还可以在形式化规格说明的基础上开发一个软件原型，让用户对该软件原型系统的界面，功能和性能进行确认，必要时，可对形式化需求说明和原型进行修改，直到形式化规格说明能正确反映用户需求为止。然后进行一系列的人机交互或全自动的程序变换，直到生成计算机系统可以接受的目标代码。2019/8/938转换模型形式化规格说明与需求比较后修正变换2变换1变换n测试形式化开发记录系统需求目标系统2019/8/939转换模型特点形式化软件开发方法形式化需求规格说明变换技术程序自动生成技术确保正确2019/8/940净室模型净室模型是一种形式化的增量开发模型。基本思想是力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。和增量模型一样，净室开发把软件看成一系列的增量，每个增量是一个形式化方法表示的“盒”。当需求收集结束后，就用盒结构表示分析和设计模型。这种“盒”是在某个特定的抽象层次上对系统（或系统的某些方面）的一次封装。完成了盒结构设计之后，先对设计的软件构件进行正确性检验；通过正确性验证后，再将形式化的盒结构设计转换为适当的程序设计语言，并进行源代码的正确性验证；接着开始统计性使用测试，即根据统计样本得出使用分布概率，按此概率进行随机测试；以上工作全部完成后，还要对增量进行集成前的认证。2019/8/941净室模型需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证增量1增量2增量n2019/8/942净室模型净室思想在分析和设计阶段消除错误在“洁净”状态下实现软件制作形式化盒结构表示分析和设计正确性验证增量模型2019/8/943小结软件开发模型是不断变化发展的各种软件开发模型各有优缺点选用时不必拘泥与某种模型可组合多种模型也可根据实际创建新的模型2019/8/944第3节软件需求分析需求分析的任务与步骤需求获取的常用方法分析建模软件需求说明结构化分析方法面向对象分析方法2019/8/945需求分析的任务和步骤需求分析的任务建立分析模型编写需求说明需求分析的步骤需求获取需求提炼需求描述需求验证2019/8/946需求获取的常用方法