软件工程-第一章 2

1,第一章软件工程概念,软件工程课件,软件工程,2,软件工程,软件工程,3,提示：设计与建模要点,结构化分析建模：数据流图、实体关系图、状态迁移图、数据字典结构化设计建模：数据流图转换为系统结构图结构化程序设计：程序流程图、N-S图、PAD程序环路复杂性计算测试用例设计：逻辑覆盖、循环测试、基本路径覆盖、因果图可靠性分析：估算测试前程序中潜在错误OMT建模：对象模型、动态模型（状态图、事件追踪图）UML建模：用例图、类图、顺序图、活动图,软件工程,4,第一章软件工程概述,1.1软件的概念、特点和分类1.2软件工程1.3软件生存周期与软件过程1.4软件过程模型1.5问题解决和范型,软件工程,5,学习重点,1、软件的概念、特点、分类2、软件危机、软件工程产生的原因3、软件工程过程和软件生命周期4、软件生命周期模型掌握几个基本概念软件危机软件工程软件过程软件生命周期软件生命周期模型,软件工程,6,1.1软件的概念、特点和分类,1.1.1软件的概念及特点软件的定义：软件由计算机程序、数据及其相关文档组成。程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料软件与硬件、数据库、人、过程等共同构成计算机系统。,软件工程,7,软件的特点,软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。软件的生产与硬件不同，在它的开发过程中没有明显的制造过程。在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。以往的软件大多是定制的，而不是装配的。软件生产正走向基于构件的组装发展（如：图形用户界面）。软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性。,软件工程,8,软件的开发至今尚未完全摆脱手工艺的开发方式软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性软件成本相当昂贵相当多的软件工作涉及到社会因素,软件工程,9,1.1.2软件的分类,按软件的功能进行划分：系统软件操作系统数据库管理系统设备驱动程序通信处理程序等支撑软件文本编辑程序文件格式化程序,软件工程,10,程序库系统软件开发环境、中间件支持需求分析、设计、编码、测试和维护的软件应用软件商业数据处理软件工程与科学计算软件计算机辅助设计制造软件智能产品嵌入软件事务管理、办公自动化软件计算机辅助教学软件,软件工程,11,可复用软件标准函数库代码复用体系结构复用开发过程的复用类库应用程序库,软件工程,12,按软件规模进行划分：类别参加人员数研制期限源程序行数微型114周0.5k小型116月1k2k中型2512年5k50k大型52023年50k100k甚大型100100045年1M(=1000k)极大型20005000510年1M10M,软件工程,13,按软件工作方式划分：实时处理软件分时软件交互式软件批处理软件按软件服务对象的范围划分：项目软件产品软件,软件工程,14,按使用的频度进行划分：一次使用频繁使用按软件失效的影响进行划分：高可靠性软件一般可靠性软件,软件工程,15,1.1.3软件的发展及软件危机,程序设计阶段1946至1956年计算机软件发展的初期，其主要特征是程序生产方式为个体手工方式。主要采用批处理技术，没有任何其它形式的文档资料保留下来，开发出的程序根本无法维护。本阶段的特点：自定义软件面向批处理,软件工程,16,程序系统阶段1956至1968年程序的规模已经很大，需要多人分工协作，软件的开发方式由“个体生产”发展到了“软件作坊”。“软件作坊”基本上沿用了软件发展早期所形成的个体化的开发方式，软件的开发与维护费用以惊人的速度增加。许多软件产品根本不能维护，最终导致出现了严重的“软件危机”。本阶段的特点：多用户、实时、数据库、软件产品,软件工程,17,软件危机1、什么是软件危机？软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。2、软件危机的表现软件价格在整个项目投入中的比例不断升高;,软件工程,18,软件开发成本严重超标;投资一再追加，令人难于置信。往往是实际成本比预算成本高出一个数量级。软件开发周期大大超过规定日期，软件开发进度难以预测；拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。软件质量难于保证；为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。系统中的错误难以消除。软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制困难。软件产品并不是没有错误，而是盲目检测很难发现错误，而隐藏下来的错误往往是造成重大事故的隐患。,软件工程,19,产品功能难以满足开发人员和用户之间很难沟通、矛盾很难统一。往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和描述。在双方互不充分了解的情况下，就仓促上阵设计系统、匆忙着手编写程序，这种“闭门造车”的开发方式必然导致最终的产品不符合用户的实际需要。软件修改、维护困难；缺乏必要的文档资料或者文档资料不合格，将给软件开发和维护带来许多严重的困难和问题。,软件工程,20,3、软件危机产生的原因？（P4）与软件本身的特点有关与软件开发与维护的方法不正确有关。4、软件危机的解决方法？为了解决软件危机，人们借鉴其他领域的经验和知识，从而认识到“摆脱软件危机的出路在于软件开发的标准化和工程化”，出现了“软件工程”的概念。,软件工程,21,软件危机的著名案例,1966年，IBM360机的操作系统。花费100万美元，1000人一年的工作量，写了近1万行代码。错误百出，每次的新版本就是从前一版本中找1000个程序错误而修正的结果，每次花费100万美元进行修改。1963年，美国用于控制火星探测器的计算机软件中的一个“,”号被误写为“.”，而致使飞往火星的探测器发生爆炸，造成高达数亿美元的损失。美国银行1982年进入信托商业领域，并规划发展信托软件系统。项目原订预算2千万美元，开发时程9个月，预计于1984年12月31日以前完成，后来至1987年3月都未能完成该系统，期间已投入6千万美元。美国银行最终因为此系统不稳定而不得不放弃，并将340亿美元的信托账户转移出去，并失去了6亿美元的信托生意商机。1996年，欧洲阿里亚纳5型运载火箭坠毁，造成5亿美元损失。原因是控制软件中的一个错误。,软件工程,22,软件危机的著名案例,1995年，StandishGroup研究机构以美国境内8000个软件项目作为调查样本，调查结果显示，有84%软件计划无法于既定时间、经费中完成，超过30%的项目于运行中被取消，项目预算平均超出189%。,软件工程,23,软件工程阶段1968年以后软件的开发以工程化的思想为指导，用工程化的原则、方法和标准来开发和维护软件。1968年，第一届NAT0（北大西洋公约组织的计算机科学家的国际会议）会议，“软件工程”的慨念作为一种有效解决“软件危机”的途径被正式提出。软件工程概念的出现源自软件危机。本阶段的特点：分布式系统、嵌入式“智能”软件、低成本硬件、消费者影响；强大的桌面系统、面向对象技术、专家系统、人工神经网络、并行计算、网络计算机,软件工程,24,1.2.1软件工程的定义1968年德国人Bauer在北大西洋公约组织会议上的定义：建立并使用完善的工程化原则,以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。1983年IEEE的软件工程定义：软件工程是开发，运行,维护和修复软件的系统方法。1993年IEEE的一个更加综合的定义：将系统化的，规范的，可度量的方法应用于软件的开发,运行和维护的过程，即将工程化应用于软件中。,1.2软件工程,软件工程,25,软件工程框架:SE=(G,P,Q),正,确,性,性,性,用,可,合,算,选取适宜的开发模型,采用合适的设计方法,提供高质量的工程支持,重视软件工程的管理,需求,实现,支持,目标,活动,原则,验证&确认,设计,1.2.2软件工程的框架,软件工程,26,软件工程框架给出了软件工程三个主要方面。软件工程目标包括可用性、正确性和合算性，规定了软件工程实践的结果（即软件）应具有的基本性质；软件工程活动包含的基本活动有需求分析、设计、实现、确认与测试、维护与支持；软件工程的四条原则-采用适宜的开发模型，使用恰当的设计方法，提供高质量的工具支持，实施有效的工程管理，从四个方面指导每一项工程的活动，以实现软件工程目标。,软件工程,27,1.2.3软件工程知识体系及知识域,2001年5月ISO/IECJTC1发布了SWEBOK指南V0.95（试用版），即GuidetotheSoftwareEngineeringBodyofKnowledge。SWEBOK把软件工程学科的主体知识分为10个知识领域。这10个领域包括：软件需求软件设计软件构造软件测试软件维护软件配置管理软件工程管理软件工程过程软件工程工具和方法软件质量,软件工程,28,SWEBOK详细结构（1）,软件工程,29,软件工程,30,1.2.4软件工程的基本原理,软件工程专家B.W.Boehm提出了软件工程的7条基本原理:1.按软件生存周期分阶段制定计划并认真实施2.坚持进行阶段评审3.实行严格的产品控制4.采用现代程序设计技术5.明确责任6.开发小组的人员应少而精7.不断改进开发过程,软件工程,31,1.3.1软件生存周期的基本任务软件生存周期定义：从形成概念开始，经过开发、交付使用、在使用中不断修改和演进，直到最终被废弃的整个时期。软件生存周期的三个阶段：软件定义、软件开发、运行修护。每个阶段又进一步分为若干阶段。,1.3软件生存周期与软件过程,软件工程,32,软件生存周期的划分,软件工程,33,1、软件定义时期,基本任务：确定软件开发工程必须完成的总目标；给出功能、性能、可靠性以及接口等方面的要求；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能估计完成该项工程需要的资源、成本、效益、开发进度。制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。通常分为问题定义、可行性研究和需求分析三个阶段。,软件工程,34,软件定义时期三个阶段的任务：问题定义阶段回答：“要解决的问题是什么？”可行性研究阶段回答：“对于上一个阶段所确定的问题，在成本和时间的限制条件下能否解决问题？是否值得做？需求分析阶段回答“为了解决这个问题，目标系统必须做什么?用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明书（specification）。,软件工程,35,2、软件开发时期,基本任务：具体设计和实现软件定义时期定义的软件。分为四个阶段。总体设计（概要设计）回答：“概括地说，应该怎样实现目标系统？”根据需求分析，设计软件的体系结构；定义结构中的组成模块。详细设计（模块设计）回答：“应该怎样具体地实现这个系统呢？”对每个模块要完成的工作进行具体的描述，为源程序编写打下基础。编写设计说明书，提交评审。二者统称系统设计。,软件工程,36,程序编写（Coding,Programming)：把软件设计转换成计算机可以接受的程序代码。软件测试（Testing):按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用，包括单元测试和综合测试。二者统称系统实现。,软件工程,37,3、运行维护（软件维护）时期,基本任务：使软件持久的满足用户的需要。包括：改正性维护：运行中发现了软件中的错误需要修正。适应性维护：为了适应变化了的软件工作环境，需做适当变更。完善性维护：当用户有新的要求时，应该及时改进软件以满足用户的要求。预防性维护:即修改软件为将来的维护活动预先做准备。,软件工程,38,ISO9000定义：软件工程过程是把输入转化为输出的一组彼此相关的资源和活动。从软件开发的观点看，它就是使用适当的资源（包括人员、硬软件工具、时间等），为开发软件进行的一组开发活动，在过程结束时将输入（用户要求）转化为输出（软件产品）。,1.3.2软件过程,软件工程,39,软件工程过程定义了:方法使用的顺序、要求交付的文档资料、为保证质量和适应变化所需要的管理、软件开发各个阶段完成的里程碑。软件工程过程包含四种基本的过程活动：plan:软件规格说明do:软件设计与实现check:软件确认action:软件演进,软件工程,40,软件过程模型也称为软件生存周期模型，它是软件工程思想的具体化，是跨越软件生存周期的系统开发、运行、维护所实施的全部活动和任务的过程框架。常用的软件生存周期模型有瀑布模型，演化模型，螺旋模型，增量模型，喷泉模型，快速应用开发（RAD）模型。,1.4软件过程模型,软件工程,41,1.4.1瀑布模型,各项活动按自上而下，相互衔接的固定次序，如同瀑布逐级下落，每项活动均处于一个质量环（输入-处理-输出-评审）中。阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档；每个阶段结束前完成文档审查。,软件工程,42,软件工程,43,瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，不适合现代的软件开发模式，其主要问题在于：各个阶段的划分固定，缺乏灵活性，阶段之间产生大量的文档，极大地增加了工作量。由于开发模型基本是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。,软件工程,44,1.4.2快速原型模型,快速原型模型也称演化模型，是基于快速开发一个满足初始构想的模型的想法提出的。它是迭代的，软件必须经过不断演化才能完善。演化模型先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。业务和产品需求在变化中，采用线性开发方式是不实际的。快速实现和提交一个有限的版本，可以应付市场竞争的压力。,软件工程,45,基本需求描述,并行活动,规格说明,开发,确认,初始版本,最终版本,中间版本,软件工程,46,软件工程,47,快速原型开发过程有两种类型：（1）演进开发过程的目的是与客户一起工作，通过一次次向客户演示原型系统并征求他们的意见，再根据他们的要求不断改进，从而深化出满足客户需求的可交付的最终系统。（2）废弃原型过程的目的是通过建立原型，借助原型与客户沟通，探索与理解客户的真正需求，据此开发出系统更良好的需求规格说明。原型起到作用后便废弃。,软件工程,48,快速原型模型有较大的灵活性，适合于软件需求不明确，设计方案有一定风险的软件项目。快速原型模型存在的三个问题：过程是不可见的如果系统是快速开发出来的，想要产生反映系统的每一个版本的文档，其代价是高昂的。系统常常构造得不合理持续的变更常常会恶化软件结构。会增加修改软件的困难、提高成本。可能要求特殊的工具和技术这些工具和技术用于快速开发，但可能与其他工具或技术不兼容，而且可能只有相当少的人具有使用这些工具或技术的技能。,软件工程,49,1.4.3形式化系统开发模型,变换模型是一种基于形式化规格说明语言及程序变换的软件开发模型。它采用形式化的软件开发方法，对形式化的软件规格说明进行一系列自动的或半自动的程序变换，最终映射成为计算机系统能够接受的程序系统。多步程序变换过程的重要性质是：每一步程序变换的正确性仅与该步变换所依据的规范Mi以及对变换后的假设Mi+1有关。,软件工程,50,在此意义上，变换步骤独立于其他变换步骤。这称为变换的独立性。该模型只适合于软件的形式化开发方法；需要严格的数学理论和形式化技术支持；需要一整套开发环境（如程序变换工具、定理证明工具等）的支持。,软件工程,51,从广义上讲，形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。狭义的讲，形式化方法是运用形式化语言，进行形式化的规格描述、模型推理和验证的方法。形式化开发方法的一些争议或缺陷主要体现在：(1)形式化方法中所包含的数学理论，限制了大多数程序设计人员的学习和使用；(2)采用形式化方法会延误项目开发周期、增加开发费用；(3)许多流行的形式化方法对于较小规模的项目是有效的，但却很难应用于一些大型系统；(4)形式化方法不能确保开发出完全正确的软件；(5)缺乏对软件生命周期内各个阶段提供全面支持的形式化方法；,软件工程,52,1.4.4面向复用的开发模型,如果将要开发的软件的设计或代码与已经开发的项目有类似的情形，经常会发生软件复用。开发人员寻找可复用的部分，按照要求加以修改以适应新的系统。面向复用的方法通常依赖于一个大的可复用软件构件库，这个构件库是一个框架，用以集成众多的构件，供使用者访问。,软件工程,53,面向复用开发的过程模型：优点：减少了软件的开发量，降低了成本和风险，缩短了软件的交付时间。,需求规格说明,构件分析,需求修改,考虑复用的系统设计,开发与集成,系统确定,中间几个阶段是面向复用过程独有的。,软件工程,54,1.4.5增量模型,增量模型是迭代和演进的过程。增量模型把软件产品分解成一系列的增量构件，在增量开发迭代中逐步加入。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。早先完成的增量可以为后期的增量提供服务。增量开发方法的新演进版本叫做极限程序设计（eXtremeProgramming）。,软件工程,55,软件工程,56,如何确定第一个增量？,软件工程,57,增量模型的优点：客户不必等到整个系统全部完成就能得到他们所需要的东西。客户可以使用较早的增量构件作为原型，用于取得经验，从而获得稍后的增量构件的需求。项目失败的风险较低。优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。增量模型的不足：客户需求分配给一定规模的增量存在较大困难。标识所有增量构件所要求的公共工具比较困难。,软件工程,58,1.4.6螺旋模型,螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型沿着螺线旋转，自内向外每旋转一圈便开发出更完善的一个新版本。制定计划风险分析实施工程客户评估,软件工程,59,软件工程,60,1.4.7喷泉模型,体现了迭代和无间隙的特性。系统某个部分常常重复工作多次，相关对象在每次迭代中随之加入演进的软件成分。无间隙是指在各项开发活动，即分析、设计和编码之间不存在明显的边界。喷泉模型是对象驱动的过程。,软件工程,61,软件工程,62,Rational统一开发过程,最佳软件开发实践为了以一种更好的、迭代的、可预测的方式开发软件产品，总结了软件开发的最佳实践：迭代式软件开发；需求管理；基于构件的软件体系结构；建立软件可视化模型；不断验证软件质量；控制变更。,软件工程,63,Rational统一开发过程软件开发过程的作用是：成为开发组活动顺序的向导。详细说明需要开发哪些制品，何时开发。指导每一个成员及整个开发组的工作。提供监控和度量项目产品和活动所依据的准则。如果没有一个良好定义的过程，开发组将各行其是，开发成功与否完全依赖个别优秀的人才，这不是能够长久的。,软件工程,64,Rational统一开发过程（RUP,RationalUnifyProcess）描述了如何在软件开发组织中严格分配任务和职责的方法。RUP是一个过程产品，软件过程也是软件。RUP采用二维的过程结构：横轴表明过程的生存周期，它反映了过程被激活时的动态情况，用周期、阶段、迭代和里程碑表示。纵轴表明过程的静态状况，通过过程构件、活动、工作流、制品和工作人员描述过程。,软件工程,65,初始,细化,构造,移交,阶段,初始化,细化#1,细化#2,构造#1,构造#2,构造#3,移交#1,移交#2,迭代,工作流,业务建模,需求,分析与设计,实现测试部署,配置和变更管理项目管理环境,沿时间轴的组织结构,沿内容轴的组织,软件工程,66,过程的静态描述：过程模型过程模型中的主要模型元素有4种：工作人员：谁做（Who）活动：怎么做（How）制品：做什么（what）工作流：何时做（when）过程的中心概念是工作人员，工作人员不是指某一个人，而是指完成工作的角色。工作人员定义人们应履行的行为和职责。,软件工程,67,活动定义了工作人员所执行的工作。有3类步骤：思考步骤执行步骤评审步骤制品是过程生产、修改或使用的一些信息。RUP的制品分为5个信息集。管理集：计划制品、操作制品需求集：构想文档、项目相关人员需求、用例模型和业务模型,软件工程,68,设计集：设计模型、软件体系结构描述、测试模型实现集：源代码和可执行程序、相关数据结构和数据文档实施集：安装资料、用户文档、培训材料工作流用来描述生成结果的活动序列，用以描述工作人员之间的交互。在RUP中共有9个核心过程工作流，包括6个核心工程工作流和3个核心支持工作流。,软件工程,69,业务建模工作流：描述业务过程的本质和执行情形。需求工作流：定义系统构想，使用用例模型和补充规格说明定义系统软件需求，管理系统范围和需求变更。分析和设计工作流：研究实现环境和系统构件的效用，定义软件的组织结构，把需求获取结果转化为实现规格。实现工作流:建立代码的分层结构，实现类和对象，进行单元测试和系统集成。,软件工程,70,测试工作流：根据事先定义的度量和准则检查产品，确认产品是否满足或者超出事先定义并被一致接受的需求。实施工作流：在实际使用环境中测试软件、包装要交付的软件、发布软件产品、培训最终用户及销售人员。核心支持工作流有项目管理工作流配置和变更管理工作流环境工作流,软件工程,71,过程的动态描述：迭代开发将一个大项目分解为可连续应用瀑布模型的几个小部分。在对一部分进行分析、设计、实现并确认后，再对下一部分进行分析、设计、实现和确认。以此进行下去，直到整个项目完成。在RUP中，迭代过程分为几个阶段。,软件工程,72,初始阶段：确定最终产品的构想及其用例，定义项目范围。细化阶段：计划需完成活动和资源，详细说明产品特性并设计软件体系结构。构造阶段：构造整个产品，逐步完善软件体系结构和计划，直到产品（完整的构想）已完全准备好交付给用户。移交阶段：移交产品给用户，包括制造，交付，培训，支持及维护产品。,软件工程,73,这4个阶段构成开发周期，周期结束时产生一代新的软件产品。软件产品产生于初始开发周期，随着重复执行同样的过程，软件发展到下一代产品，这一时期即为软件的进化周期。,软件工程,74,Rational统一过程的特点：用例驱动的、以体系结构（架构）为中心的、迭代和增量的过程。用例建模技术可以用为大多数项目相关人员理解的形式来表述问题。参与者（Actor）用例（UseCase）场景（scenario）事件流（eventflow）,软件工程,75,用例和参与者的事例银行储户通过自动取款机（自动柜员机）提款，转账或检查账户余额。用一组用例表达如下：,软件工程,76,用例模型将整个系统或子系统的所有用例，以及与之交互的参与者集合起来构成系统的用例模型。用例模型给出系统预期功能模型和系统上下文环境模型，它成为开发人员和用户之间的契约。用例模型的目的是确保系统能处理所有的功能性需求。,