【文档说明】软件工程概述课件.ppt,共(82)页,997.500 KB,由小橙橙上传
转载请保留链接:https://www.ichengzhen.cn/view-45011.html
以下为本文档部分文字说明:
软件工程概述方海光首都师范大学教育技术系2008年9月fang.csai.cn2课程内容软件工程概述SE面向对象软件工程OOSE面向对象分析与设计UML面向对象程序设计C++(选择)设计模式初步:DesignPatterns(选择)SOA:ServiceOrientedArc
hitecture(选择)AOP:Aspect-OrientedSoftwareDevelopment项目设计实践:WebApplicationDevelopmentusingUMLWeb2.0PMfang.csai.cn3
Contents软件危机(1)软件危机(1.2)软件工程(2)软件生命周期(3)软件过程(4)软件工程的目标fang.csai.cn4Contents1软件危机fang.csai.cn5fang.csai.cn6软件危机表现成本进度估计不准确变动频繁的软件需求软件
质量不可靠软件维护困难没有适当的文档资料软件在系统总成本比例上升软件发展速度赶不上硬件fang.csai.cn7软件危机原因软件本身特点:逻辑不可预见软件开发和维护的方法不正确fang.csa
i.cn8消除软件危机途径技术上:方法、工具管理上:组织、经验fang.csai.cn9Contents软件危机(1.2)软件工程(1.2)fang.csai.cn10软件工程的定义Boehm:运用现代科学技术知识来设计并构造计算机程序及为开
发、运行和维护这些程序所必需的相关文件资料IEEE:软件工程是开发、运行、维护和修复软件的系统方法FritzBauer:建立并使用完善的工程化原则,以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法fang.csai.cn11软件工程三要素:方法、工具和过程软件
工程方法为软件开发提供了“如何做”的技术软件工具为软件工程方法提供了自动的或半自动的软件支撑环境fang.csai.cn12软件工程过程定义了:方法使用的顺序要求交付的文档资料为保证质量和适应变化所需要的管理软件开发各个阶段完成的里程碑fang.csai.c
n13软件工程七条基本原理1用分阶段的生命周期计划严格管理这一条是吸取前人的教训而提出来的。统计表明,50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中,需要完成许多性质各异的工作。这条原理意味着,应该把
软件生命周期分成若干阶段,并相应制定出切实可行的计划,然后严格按照计划对软件的开发和维护进行管理。Boehm认为,在整个软件生命周期中应指定并严格执行6类计划:项目概要计划、里程碑计划、项目控制计划、产品控
制计划、验证计划、运行维护计划。fang.csai.cn14软件工程七条基本原理2坚持进行阶段评审统计结果显示:大部分错误是在编码之前造成的,大约占63%;错误发现的越晚,改正它要付出的代价就越大,要差2到3个数量级。因此,软件的质量保证工作不能等
到编码结束之后再进行,应坚持进行严格的阶段评审,以便尽早发现错误。fang.csai.cn15软件工程七条基本原理3实行严格的产品控制开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们,需求的改动往往是不可避免的。这就要求我们要采用科
学的产品控制技术来顺应这种要求。也就是要采用变动控制,又叫基准配置管理。当需求变动时,其它各个阶段的文档或代码随之相应变动,以保证软件的一致性。fang.csai.cn16软件工程七条基本原理4采纳现代
程序设计技术从六、七时年代的结构化软件开发技术,到最近的面向对象技术,从第一、第二代语言,到第四代语言,人们已经充分认识到:采用先进的技术即可以提高软件开发的效率,又可以减少软件维护的成本。fang.csai.cn17软件工程七条基本
原理5结果应能清楚地审查软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差,难于评价和管理。为更好地进行管理,应根据软件开发的总目标及完成期限,尽量明确地规定开发小组的责任和产品标准,从而使所得到的标
准能清楚地审查。fang.csai.cn18软件工程七条基本原理6开发小组的人员应少而精开发人员的素质和数量是影响软件质量和开发效率的重要因素,应该少而精。这一条基于两点原因:高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍,开发工作中犯的错误也要少的多;当开发小组为N人时,
可能的通讯信道为N(N-1)/2,可见随着人数N的增大,通讯开销将急剧增大。fang.csai.cn19软件工程七条基本原理7承认不断改进软件工程实践的必要性遵从上述六条基本原理,就能够较好地实现软件的工程化生产。但是,它们只是对现有的经验的
总结和归纳,并不能保证赶上技术不断前进发展的步伐。因此,Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理,不仅要积极采纳新的软件开发技术,还要注意不断总结经验,收集进度和消耗等数据,进行出错类型和问题报告统计。这些数据既可以用来评估
新的软件技术的效果,也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。fang.csai.cn20软件工程方法学传统方法学(结构化软件开发)可行性分析,需求分析,总体设计,详细设计,编码,测试,维护软件项目管理面向对象方
法学(面向对象软件开发)面向对象分析OOA,面向对象设计OOD,面向对象实现OOP,面向对象测试OOT,面向对象维护OOM面向对象的软件项目管理fang.csai.cn21Contents软件(1.1)软件危机(1.
2)软件工程(1.2)软件生命周期(1.3)软件开发模型(1.4)软件工程的目标fang.csai.cn22软件生命周期lifecycle软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生命周期三个时期:定义、开发、维护软件生存期的七个步骤,即可行性研究
、需求分析、总体设计、详细设计、程序编码、单元测试和集成测试、维护fang.csai.cn23Contents软件(1.1)软件危机(1.2)软件工程(1.2)软件生命周期(1.3)软件过程(1.4)软件工程的目标fang.csai.cn24软件生存期模型软
件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架•瀑布模型•原型模型•螺旋模型•…fang.csai.cn25“What——How——Change”概括了软件开发活动(定义、开发、维护)中的主要
特征。传统的软件开发模型主要有瀑布模型与快速原型模型。fang.csai.cn26瀑布模型需求定义系统与软件设计集成与系统测试实现与单元测试运行与维护各项活动按自上而下,相互衔接的固定次序,如同瀑布逐级下落。每项
活动均处于一个质量环(输入-处理-输出-评审)中。fang.csai.cn27瀑布模型fang.csai.cn28fang.csai.cn29制定计划确定要开发软件系统的总目标;给出功能、性能、可靠性以及接口等方面的要求;完成该软件任务的可行性研究;估计可利用的资源
(硬件,软件,人力等)、成本、效益、开发进度;制定出完成开发任务的实施计划,连同可行性研究报告,提交管理部门审查。fang.csai.cn30需求分析和定义对用户提出的要求进行分析并给出详细的定义;编写软件需求说明书或系统功能说明书及初步
的系统用户手册;提交管理机构评审。fang.csai.cn31软件设计概要设计—把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块,每个模块都和某些需求相对应;详细设计—对每个模块要完成的工作进行具体的描述,为源程序编写打下基础;编写设计说明书,提交评审。fan
g.csai.cn32程序编写把软件设计转换成计算机可以接受的程序代码,即写成以某一种特定程序设计语言表示的“源程序清单”;写出的程序应当是结构良好、清晰易读的,且与设计相一致的。fang.csai.cn33软
件测试单元测试,查找各模块在功能和结构上存在的问题并加以纠正;组装测试,将已测试过的模块按一定顺序组装起来;按规定的各项需求,逐项进行有效性测试,决定已开发的软件是否合格,能否交付用户使用。fang.csai.cn34运行/维护纠正性维护运行中发现了软件中的错误需要修正;适应性维护为了
适应变化了的软件工作环境,需做适当变更;完善性维护为了增强软件的功能需做变更。fang.csai.cn35按照传统瀑布模型开发软件的特点1.阶段间具有顺序性和依赖性。2.推迟实现的观点。3.每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。fan
g.csai.cn36传统瀑布模型开发软件带来的问题:过程基本不可迭代需求在开始的不确定性错误到最后才能发现开发进程呈现塞阻状态fang.csai.cn37软件生存期循环fang.csai.cn38快速原型模型快速原型模型(RapidPrototy
peModel)的主要做法是:首先建立一个能够反映用户主要需求的原型,让用户实际看一看未来系统的概貌,以便判断哪些功能是符合需要的,哪些方面还需要改进。快速原型系统的优越性主要体现在:软件开发人员向用户提供一个“样品”,用户向开发人员迅速作出“反馈”。fang.csai.cn39快速原型
模型图示用户测试,运行原型建造修改/原型听取用户意见fang.csai.cn40原型模型原型产生步骤fang.csai.cn41如何产生快速原型系统?原型系统仅包括未来系统的主要功能,以及系统的重要接口。为了尽
快向用户提供原型,开发原型系统时应尽量使用能缩短开发周期的语言和工具。把原型系统作为基础,通过补充与修改获得最终的实际系统。fang.csai.cn42快速原型模型带来的问题:需要足够的人力资源•用户和设计都成为关键适用于MIS形式的系统fang.csai.cn43增量模型(递增模
型)先完成一个系统子集的开发,再按同样的开发步骤增加功能(系统子集),如此递增下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应作出设想。fang.csai.cn44增量模型分析设计编码测试分析设计编码测试分析设计编码测
试分析设计编码测试增量2增量3增量4增量1第1个增量的发布第2个增量的发布第3个增量的发布第4增量的发布要点:•顺序过程和原型过程相结合•强调版本升级•每个版本的开发遵循顺序过程fang.csai.cn45增量模型
把软件产品分解成一系列的增量构件,在增量开发迭代中逐步加入。每个构件由多个相互作用的模块构成,并且能够完成特定的功能。增量开发方法的新演进版本叫做“极限程序设计(eXtremeProgramming)”。定义基本需求将需求赋
予增量构件设计系统体系结构开发增量构件确认增量构件集成增量构件确认系统fang.csai.cn46螺旋模型结合瀑布模型与快速原型的基础上增加了风险分析fang.csai.cn47螺旋模型螺旋模型沿着螺线旋转,在四个象限上分别表达
四个方面的活动,即:制定计划确定软件目标,选定实施方案,弄清项目开发的限制条件;风险分析分析所选方案,考虑如何识别和消除风险;实施工程实施软件开发客户评估评价开发,提出修正建议。fang.csai.cn48螺旋模型决定目标、方案和限制评价方案、识别风险、弱化风险开发、验证、下
一级产品计划下一阶段集成测试fang.csai.cn49风险分析工程构造及发布用户评估客户交流计划项目入口螺旋模型轴线与增量模型的区别:•活动划分不同•更强调“计划”、“风险分析”和“用户评估”•版本有更明确的目标要点:相似于增量模型,是顺序过程与
原型过程的统一,强调版本和版本升级。版本的明确目标:概念项目→增量项目→维护项目fang.csai.cn50当前的软件的价值动力源泉,世界不可或缺的一部分规模、复杂性、分布和重要性不断扩张生产和维护越来越难熟悉的软件开发方法
收到限制fang.csai.cn51软件开发问题的症状对于最终用户的需要理解得不够精确对需求的改变束手无策程序块不兼容软件不易维护或不易扩展对项目严重缺陷的发现较晚软件质量低劣软件性能令人无法接受开发组的人
员按各自的方式进行开发,如果有人改变可部分软件,将很难进行重组一个不可靠的构造和发布过程fang.csai.cn52失败原因特别的需求管理模糊和不精确的交流脆弱的构架过度复杂未检测出需求、设计和实现之间
的不一致测试的不足对于项目状况的评估过于主观未解决存在的风险无法控制变化的产生和传播自动控制不足fang.csai.cn53最佳软件开发实践BestPractices迭代地开发软件DevelopIteratively管理需求ManageRequirements
应用基于构件的构架UseComponentArchitectures为软件建立可视化的模型ModelVisually(UML)不断地验证软件质量ContinuouslyVerifyQuality控制软件的变更ManageChangefang.cs
ai.cn54BestPracticesReinforceEachOther:AnExampleValidatesarchitecturaldecisionsearlyonAddressescomplexityofdesign/implementationincrementa
llyMeasuresqualityearlyandoftenEvolvesbaselinesincrementallyEnsuresusersinvolvedasrequirementsevolveBestPracticesDevelopIterativelyMana
geRequirementsUseComponentArchitecturesModelVisually(UML)ContinuouslyVerifyQualityManageChangefang.csai.cn55现在软件产业界普遍认为,开发复杂软件项目必须采用基于UM
L的、以构架为中心、用例驱动与风险驱动相结合的迭代式增量开发过程,他是世界公认的开发复杂软件项目的最好过程,已经成为软件界的“圣经”。这一开发过程目前已经稳定、成熟。这就是:RUP—RationalUnifiedProcessfang.csai.cn
56RationalUnifiedProcess—RUPRational统一过程是由Rational软件公司开发和营销的一种软件工程过程,是开发组织用以分配与管理任务和职责的一种规范化方法。这个过程的目的是在预定的进度和预算范围内,开发出满足
最终用户需要的高质量软件。fang.csai.cn57RUPImplementsBestPracticesBestPracticesProcessMadePracticalDevelopIterativelyManageRequirementsUseComponentArch
itecturesModelVisually(UML)ContinuouslyVerifyQualityManageChangefang.csai.cn58软件开发过程为开发小组的活动顺序提供向导详细说明那些制品将被开发,以及什么时候开发指导每
一个开发人员和整个开发组的工作为监控和度量项目的产品和活动提供准则fang.csai.cn59RUP将这些最佳实践活动以一种适当的形式结合起来,从而适应了广泛的项目和开发组织。fang.csai.cn60RUP是
一个过程产品(processproduct)。Rational(IBM)软件公司开发并维护着这个产品,并将其与Rational软件公司自己的一系列软件开发工具集成。fang.csai.cn61RUP有自己的过程框架(processframework
),这个框架可以被改造和扩展以适应采纳此方法的组织。fang.csai.cn63•RationalProcessWorkbench•Majoradditionofcontent•Majoradditionoftoolmen
torsImprovedProcessforindependenttestingRationalObjectoryProcess4.11997RationalObjectoryProcess4.01996RationalUnifie
dProcess5.01998RationalUnifiedProcess2000RationalUnifiedProcess2001RationalUnifiedProcess5.51999Ratio
nalUnifiedProcess2002RationalUnifiedProcess2003RationalApproach•ProjectManagement•UML1.3•RealTime•PerformanceTesting•BusinessModeli
ng•Configuration&ChangeMgt•ObjectoryUIDesign•DataEngineering•UML1.1•OMT•Booch•UML1.0•Requirements•TestProcess•Treebrowserupgraded
forenhancedcapabilitiesofcreatingcustomizedMyRUPtree•IntroductionofRUPPlatformprovidingaconfigurableprocessframeworkObjectoryProcess3
.8HistoryofRUPfang.csai.cn64RUP特点用例驱动以体系结构为中心增量和迭代开发fang.csai.cn65用例驱动•用UseCase作为划分问题的组织单元,分析和设计活动的局部粒度都遵循这
一划分原则。UseCase的定义反映可系统外部要素根据特定目标使用拟建系统的状况,能确保问题的局部划分粒度适当,保持了全局与局部的平衡。fang.csai.cn66fang.csai.cn67增量和迭代开发基于风险前驱的原则,渐进地展开分析、设计及其相关活动,每个迭代
都会提供一次验证和调整模型机会,推动软件质量的提升。fang.csai.cn68RUP二维过程结构沿时间轴的组织结构沿内容轴的组织结构fang.csai.cn69RUP的生命开发周期fang.csai.cn70RUP的生命开发周期fang.csai.cn71RUP的生命开发周期
fang.csai.cn72RUP的生命开发周期fang.csai.cn73主要困难•多层次持续的规划与评估•判断架构中关键风险的经验•高效率的验证和评价手段•多工种之间的频繁沟通•多版本工作产品的管理fang.csai.cn74fa
ng.csai.cn75fang.csai.cn76fang.csai.cn77fang.csai.cn78fang.csai.cn79RUP的裁减RUP仅仅是一个通用的过程框架,需要根据实际情况裁减。fang.csai.cn80fang.csa
i.cn81Contents软件(1.1)软件危机(1.2)软件工程(1.2)软件生命周期(1.3)软件开发模型(1.4)软件工程的目标fang.csai.cn82软件工程项目的基本目标付出较低的开发成本达到要求的软件功能取得较好的软件性能
开发的软件易于移植需要较低的维护费用能按时完成开发工作,及时交付使用软件工程