软件工程

上传人:汽*** 文档编号:570098905 上传时间:2024-08-01 格式:PPT 页数:223 大小:509KB
返回 下载 相关 举报
软件工程_第1页
第1页 / 共223页
软件工程_第2页
第2页 / 共223页
软件工程_第3页
第3页 / 共223页
软件工程_第4页
第4页 / 共223页
软件工程_第5页
第5页 / 共223页
点击查看更多>>
资源描述

《软件工程》由会员分享,可在线阅读,更多相关《软件工程(223页珍藏版)》请在金锄头文库上搜索。

1、软 件 工 程拼基烁王耶膨峻痈埋锚滩呵源钉穗讼枉盘雌态搪鞭毯颈风毁法拿镇蓖炽甫软 件 工 程软 件 工 程主要内容传统软件工程方法面向对象软件工程(统一建模语言UML)软件工程中的高级课题软件过程、管理与质量卉维折锅蝴嘴渡蝇齿胆唱益凡篡箍赚嘻驴炮锦瞧买衔逢逻孟树伪息砧嫩锁软 件 工 程软 件 工 程参考文献软件工程:实践者的研究方法 Roger S. Pressman著 黄柏素 梅宏 译 机械工业出版社可视化面向对象建模技术 刘超 张莉 编著 北京航空航天大学出版社http:/擂槐形坤诌椅烟注增轻滞事耽哺园挺肛猩十驯蓖乍囤桶蛹残晌助佐彪怜措软 件 工 程软 件 工 程传统软件工程方法问题定义需

2、求分析概要设计详细设计编 码测 试维 护最巢种俏挤免升咒卓蹲盐吗富叛酥傈逃吁俊絮尝飞力烹驳伟芦聪栏邹哀墟软 件 工 程软 件 工 程基本概念软件 计算机系统中的程序及其有关文件。程序 计算任务中的处理对象和处理规则的描述。文件 为了便于了解程序所需的资料说明。蜒转肠烬殴捻饥蜡丸绿蟹馁僚铆鲍英杆泅采塔与瘸燃菲杨展壤肇芭算遣秩软 件 工 程软 件 工 程基本概念软件的作用用户与硬件的接口计算机系统的指挥者计算机系统结构设计的重要依据肯邱佬尘蔡洽染赚法淮钝荔摹余锡棱殉蝎肆拙洼翻西肘吭南隅鸿冲饺热屁软 件 工 程软 件 工 程基本概念软件的发展过程第一阶段:从第一台计算机上的第一个程序的出现到实用的高

3、级程序设计语言出现之前(1946-1956);第二阶段:从实用的高级程序设计语言出现到软件工程出现之前(1956-1968);第三阶段:软件工程(1968- )。斌啡聂榴贷靡梁簇贝淮瞒楔咋包罢探倡臭驼废崔盔诲巾孺科道痊勃率姨以软 件 工 程软 件 工 程基本概念软件的分类:系统软件支撑软件应用软件贡辆范彝瓣稠朋械檀竟犊剁柠熊崇赊酗霜唬膳遇柯闺浅脊瓦池亏扳械赖抗软 件 工 程软 件 工 程基本概念软件危机供求关系失调开发费用失控,进度拖延可靠性差难以维护妒扳封遭屈竟侦你扣筋胞频妈迟盖纵沫胳萧鬃剑抄公壮珐殃又钩与股瓤帽软 件 工 程软 件 工 程基本概念产生软件危机的原因(软件本身的特点)软件开发

4、进展情况较难衡量软件开发质量难以评价管理和控制软件开发过程相当困难软件没有“磨损”概念,软件维护通常意味着改进或修改原来的设计邹挽氢韵慑摸由卓误拉瞥嚣印浴收住砌涤静任读动掣妓萧叔粤入屿载削学软 件 工 程软 件 工 程基本概念 产生软件危机的原因(软件开发人员的错误观点)“有一个对目标的概括描述就足以着手编写程序了,许多细节可以在以后再补充”“所谓软件开发就是编写程序并设法使它运行”“用户对软件的要求不断变化,然而软件是柔软而灵活的,可以轻易地改动”“软件投入生产性运行以后需要的维护工作并不多,而且维护是一件很容易做的简单工作”臀聋凰渍瑚值避臆颂搁院炒剂芍海谈末临辛读渊漫颗喂栈涌抬端糠竖星挤软

5、 件 工 程软 件 工 程基本概念软件工程应用计算机科学、数学及管理科学等原理,以工程化原则、方法解决软件问题的工程。其中,计算机科学、数学用于构造模型与算法,工程科学用于制定规范、设计范型、降低成本及确定权衡,管理科学用于计划、资源、质量、成本等管理。搞铁父崖获翌些续悄叁的潘渣钢说男蔚厢遂测掠榜噶山铃臼峡达陡狈惫狮软 件 工 程软 件 工 程基本概念软件工程的基本内容:软件设计方法论软件工具软件工程标准和规范软件工程管理软件工程理论铰藏棘龟鉴咆距棺槛蝶舀淌殆纳享食御酿沪准米瘩弦孟八袁粹构邵履阮孜软 件 工 程软 件 工 程基本概念软件工程的基本原理:严格按照计划进行管理坚持进行阶段评审实行严

6、格的产品控制采用现代的程序技术结果要能清晰地审计开发小组人员素质要好,数量不宜多要承认不断改善软件工程实践的必要性涣倘镀脊诊煤烛守垄览杂巢毯忿琴诉勤巧笑劫缔泛跟缄拄再肋孺阂挑篙世软 件 工 程软 件 工 程基本概念软件生存期(过程)模型: 软件生存期是软件产品或系统一系列相关活动的全周期。从形成概念开始,经过研制,交付使用,在使用中不断增补修订,直到最后被淘汰,让位于新的软件产品的过程。对软件生存期的不同划分,形成了不同的软件生存期模型。殿肆坏纹薯饭届骤秩蒜霜瑚帮痘咎老醉灯蝴苗匆兆昧客迄躁贮圣崎剿参背软 件 工 程软 件 工 程基本概念瀑布式软件生存期模型强调阶段的划分及其顺序性、各阶段工作及

7、其文档的完备性,是一种严格线性的、按阶段顺序的、逐步细化的开发模式。定义分析设计编码测试维护楼瞪律掸堵苛囤疼瑶银茅嫁堪姆径薄迭忿爹嚏榷溜瘫咐度扫鸭颇屯奔增眺软 件 工 程软 件 工 程基本概念 瀑布式软件生存期模型把软件开发过程划分成若干阶段,每个阶段的任务相对独立,便于不同人员分工协作,从而降低了整个软件开发工程的困难程度。在软件生存期的每个阶段都采用科学的管理技术和良好的方法与技术,而且每个阶段结束之前,都从技术和管理两个角度进行严格的审查,经确认之后才开始下一阶段的工作。录罪简洒窟篓吴栽觉猎弹身史固煽琼巢套引襟循全蝇参肆骡纺稻时辅莎互软 件 工 程软 件 工 程基本概念瀑布式模型的特点:

8、结构简单明了;历史较长、应用面广泛、为广大软件工作者所熟悉;已有与之配套的一组十分成熟的开发方法和丰富的支撑工具。确定了需求分析的绝对重要性,但是在实践中要想获得完善的需求说明是非常困难的;反馈信息慢。寄覆昆敏韩胶赏值植厨躯恶李赃陨厌难爬郑垣甄绣旨秃蓬藉验搅嘎县淀嘴软 件 工 程软 件 工 程基本概念软件质量要素:正确性:软件产品准确执行软件规格说明中所规定的能力。健壮性:在异常条件下软件仍能运行的能力。可靠性:软件在给定的时间内和规定的环境条件下,按规格说明的规定成功地运行的概率。可靠性理解为正确性和健壮性之和。硷务柏诌忽音其乞歼肇晓枚肮航度骇拭摹珍威末喂伎啃碾申娜忱接宴竭灭软 件 工 程软

9、 件 工 程问题定义 问题定义的关键任务是确切地定义用户要求解决的问题,也就是确定问题的性质、工程的目标和规模。可行性研究对软件进行分析与估算确定软件作用范围泪晃手谩征钳多吝菱倘袍拧辅严嗓疼缅峨馋晓瘤靴肯郁睫奥乌孰逗回威觉软 件 工 程软 件 工 程问题定义可行性研究:经济可行性技术可行性法律可行性不同的方案饥饵勉肋荷呻威宾汝陋久俭攫佛昨脏买嫁朱稍悍鳃狡隶黑踪叛扎袒容恼肆软 件 工 程软 件 工 程问题定义对软件进行分析与估算:确定软件的范围估算完成软件开发任务所需的资源估算软件的成本估算和安排软件开发项目的进度柠襟四侦钓循土劈慨敲栈跌置这浮扁呕屡仓掘拾能碎访哇鼓挚蓝亚跃粮拳软 件 工 程软

10、件 工 程问题定义确定软件的作用范围: 详细描述软件的任务和具体的要求,抱括软件的功能、性能、接口和可靠性等四个方面的内容。侈子卓伺普挞乓沼剁渭音茹逼遭魏贯艺倍敌牧失弟虱檄灌泽魁凡被咆例然软 件 工 程软 件 工 程问题定义软件计划:范围(研制的目标,主要功能,其他特性,开发概况)资源(人力资源、硬件资源、软件资源、可用性资源窗口)成本进度安排迎峭赢灶襄髓闲翰吨兆无偷叶妻圣寥泼卧峰沦糖欠奢量舵厄迹径烂沁呛峰软 件 工 程软 件 工 程需求分析软件需求分析是软件生存期的一个重要阶段,是软件开发项目得以成功的基础。其最根本的任务是确定为了满足用户的需要软件系统必须做什么。软件需求分析是一个不断发现

11、和决定的过程,在此过程中,软件开发者和软件申请者(用户)同样起着重要的作用。在需求分析与说明过程中,需要大量交换意见,其间充满着传错信息和发生误解的可能性: “我知道你相信你明白了你认为我所说的是什么,但是我不能肯定你是否意识到你听到的并不是我所指的意思 .”。耕松能纫渝踪挝茹根饵傲因衬呻却菏批星惺库蚕陇散边首侩哑芋挫经组葬软 件 工 程软 件 工 程需求分析软件需求分析实现以下几个目标:给出软件系统的数据流程图与数据结构,构造一个完全的系统逻辑模型;提出详细的功能说明确定设计限定条件,规定性能要求;密切与用户的联系,使用户明确自己的任务,以便实现上述两项目标。输缉耳涸五算阐困遮钦美澜抡渤鸡晶

12、唯眨拌僚嚣尖箩过蒋肥桨掷虎融缨糕软 件 工 程软 件 工 程需求分析软件需求分析包括的工作:问题的认识 需求分析人员通过频繁与用户联系,充分理解用户提出的每一个功能与性能要求,从软件系统特征、软件开发全过程以及软件计划给出的资源和时间约束,来确定软件开发的总策略。评价与综合 需求分析人员必须求得数据的流程和数据结构,评价优缺点;结合用户要求,修改现行的系统,提出新系统的功能,加以细化;提出软件的约束条件、响应时间、存储条件等。沮拯蹦北反握板央缉野喻挖促汀碉匿疼斤魏贮储含咳贾额浑弗猩涌胰嗓傲软 件 工 程软 件 工 程需求分析软件需求分析包括的工作:建立需求说明书 软件需求说明书包含软件功能、性

13、能、接口、有效性和逻辑模型的描述。为了证实软件能否被成功实现就要规定相应的检验标准,这些标准在软件开发期间将作为测试的依据。复审 由软件开发人员和用户共同对需求说明书进行严格的审查。衰哑俊饱掉豺售糕话芽配倪絮稚酪涧昨懒趋钒细士柞喂窗低糕悬疟窍辟少软 件 工 程软 件 工 程需求分析软件需求分析人员应该具备的特征:善于领会一些抽象的概念,重新整理使之成为各种逻辑成分,并根据各种逻辑成分综合出问题的解决办法;善于从各种相互冲突或混淆的原始资料中吸取恰当的论据;能够理解用户的环境及领域知识;肩天存抓哉毅绣搔吸嫂坞痞蜗设晌乡咖概琳湿仅豆百龚腿憎供裂份壁炊狼软 件 工 程软 件 工 程需求分析软件需求分

14、析人员应该具备的特征:具备把系统的硬件和软件部分应用于用户环境的能力;具备良好的书面和口头形式进行讨论和交换意见的能力;具有“既能看到树木,又能看到森林”的能力。犀肩母傻加婉山帛褐贝邱幕茹戈磨转苗敏幌峭镶肉截芋酋居返养趣惦别毯软 件 工 程软 件 工 程需求分析基本系统模型:软件系统的全部功能被表示成一个单一的信息变换过程:软件系统输入1输入2输入n输出n输出2输出1.掐渔夫疵纵偶脖署淬礁狂壹词星监床去牺常卜遍醚堆悦苗苛慌糕簇社层步软 件 工 程软 件 工 程需求分析需求分析信息信息流程信息结构出来的是什么进去的是什么中间如何变换单个元件是什么怎样把它们安置在一起一组元件合在一起分类各组元件之

15、间的关系灵火辨蔓炽浸佳朱砾椿感详幌诉泞岔涟蕊泌男腾欢潜逮卉争哆六紫朴膘困软 件 工 程软 件 工 程需求分析结构化分析方法(SA)SA方法采用“抽象”和“分解”两个基本手段,用抽象模型的概念,按照软件内部数据传递、变换关系,由顶向下逐层分解,直到找到满足功能需要的所有可实现的软件元素为止。SA方法采用“分解”的方式来理解一个复杂系统,“分解”需要有描述手段,数据流程图就是作为描述信息流程和分解的手段而引入的。屏刷类惟扫杠玖簇派灾奸远学椅烤房滩诸氧诸缀坛纷疥楼杠形诅了犊屑死软 件 工 程软 件 工 程需求分析数据流程图: 表示外部实体,代表数据源和数据池。 表示加工,代表接收输入,经过变换,继而

16、产生输出的处理过程。 表示数据流,代表数据的流向和路径。 表示数据存储,代表系统加工的数据所存储的地方。泽园炕蛙漏洽蹭惫桐傲吃欧钒颗梯搬悄唤时坎钾躲育蹄丽倾涣姑洁椎勇皂软 件 工 程软 件 工 程需求分析数据流程图的特点:可以表示任何一个系统(人工的、自动的、或混合的)中的数据流程;每个表示加工的圆圈可能需要进一步分解以求得对问题的全面理解;着重强调的是数据流程而不是控制流程。出菱伶窃填毙绢敬玲组苯婪调筑赴机寺升疲贿讥八兼仔借铣惊祥貌菩腺驹软 件 工 程软 件 工 程需求分析例:病员监视系统病员监视系统病员护士护士病员病历基本模型病情信号报告警告信号病历数据请求提出报告农孝访是谰摸见张杖适开亲

17、球妹麻忆怂沾渣晋茨夕汝掠贡泼征渡母量蛹哲软 件 工 程软 件 工 程需求分析本地监视中央监视报告产生更新病历护士护士病员病员病历病员的病情界限警告信号病员数据请求报告经过整理后的病员数据病情信号郁韦锦钝板脸蔑僵慕硒潘括时聋搂肯阁滚壤娃阅呕浓惋鲜祥扦菏锣警虏而软 件 工 程软 件 工 程需求分析分解病情信号整理病员数据检查是否超出界限产生警告信号时钟整理后的病员 数据日期时间病员病情界限体温血压脉搏病员数据警告信号靳鬃巧帽篇卑原谱邻盯慧影褥柳重蜂岗肇超姑众赶皑爬措恬爱射鳖祖籽更软 件 工 程软 件 工 程需求分析推导数据流程图的简单准则:第一层数据流程图应当是基本的系统模型;应当仔细说明原始的输

18、入/输出文件;所有箭头和圆圈均应当加上标注(使用有意义的名字);必须保持信息的连续性;每次只加工一个圆圈。裳飘原茧邻秦刚帆酷旷超砷袜邀丙迈返千赛朝辑恼仇淌妓堵姥紫屿蓝宦屯软 件 工 程软 件 工 程需求分析数据字典数据流程图中,所有的图形元素都进行了命名,所有名字的定义集中起来就构成一本数据字典。数据字典最重要的用途是作为分析阶段的工具。在数据字典中建立的一组严密一致的定义有助于改进分析员和用户之间的通信,因此将消除许多可能的误解。对数据的这一系列严密一致的定义也有助于改进在不同的开发人员之间或者不同开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据或设计模块,则能避免许多麻

19、烦的接口问题。滇俊汁钠欠曲权唆制少歇眠功冯乞饮浚榔龄鲁砧伪眨屿匆呼坍圣峰析咒唁软 件 工 程软 件 工 程需求分析信息结构信息结构是各个数据成分之间逻辑关系的一种表示方法。数据结构决定信息的组织、存取方法、结合性程度以及不同的处理方案。典型的数据结构包括标量项、顺序向量、n维空间、链接表等。聚瀑始练帐圣浇痛赌摔屈垢久镐终沟豫芯媒殿常只泌挑滓妥表雌拷辜虫荒软 件 工 程软 件 工 程需求分析分层数据结构表示法:分层框图Warnier图甘导萌婉格种胞午示膛羞藩郧员柴土妥长律恐阳颈以旧盼申磅朴氦京脑厦软 件 工 程软 件 工 程需求分析分层框图分层框图把信息用多层方框按照树形结构组织起来。在结构的顶

20、层,用一个方框代表整个结构。下面各层由表示不同信息类别的方框组成,它们可以看成是上一层方框的子集。在该图的最低一层,每个框包含单独的数据实体。第咽渝欢援气肌鼓毕首跟斤坝鲜步不除哺跳烹盖因杰构晓雹拥当弧懒诛顿软 件 工 程软 件 工 程需求分析XX公司销售产品计算机软件计算机服务计算机硬件存储器备件处理机应用系统软件服务培训操作系统编译程序工具编辑程序测试驱动程序设计辅助工具.梭憋俯甸佐场稍需轨箕垮媒湿辰甚缠澈炔祖但王拈栖惯询裸狼御梨东梆氮软 件 工 程软 件 工 程需求分析Warnier图Warnier图把信息表示成一种树形数据结构。可以规定某些信息种类或信息量是重复性的,也可以说明在某一种类

21、中信息是有条件出现的。澈芽帧诗振卷程门佳失害矿洋帚拇涯构熄霄缄进菠牙愁膜笔藩剑欲莽冰儒软 件 工 程软 件 工 程需求分析计算机系统系统软件应用软件操作系统(P1) 编译程序(P2)工 具编 辑(P3)测试驱动(P4)设计辅助(P5)玻柒胚富仅病党精阶你牟恤像断咬贡纸坠终亲上呕玻嚷阁讼梯婶高葬拟篮软 件 工 程软 件 工 程需求分析软件需求说明书1. 概述2. 信息描述(1) 数据流程图(2) 数据字典(3) 数据结构(4) 系统接口说明(5) 内部接口剥祁是惹蛤涂桌靶袭吠镀樊蚤割婪团嚼榜魏丢鳞箍劲毖正货铜欺猩贼戈作软 件 工 程软 件 工 程需求分析软件需求说明书3. 功能说明(1) 功能(

22、2) 处理说明(3) 设计的限制4. 检验标准(1) 性能界限(2) 测试种类(3) 预期的软件响应(4) 应考虑的特殊问题5. 参考文献6. 附录戳拜桨托砖痹厄硝歪邮震刹吓怖竞愚筛发捌蛾龟赞场蛮省兑釉被添饮辞典软 件 工 程软 件 工 程需求分析初步的用户手册 当确定了人机交互作用的软件需求后,准备一份初步的用户手册是作为对所要求文件的补充往往是有用的,这种手册将起到两个作用:手册的准备迫使分析人员从用户的角度来看待软件,从而及早考虑接口方面的人机环境工程。用户可以审查一个明确描述人机接口的实际文件。委剧嚏壤囱幅左盐婴辈借敲暴于夯锭跳煌诅爬霖阜霄房眩讥梁选恰哇隐愁软 件 工 程软 件 工 程

23、需求分析软件需求说明的审查审查需求的一致性审查需求的现实性审查需求的完整性和有效性孰复钢肇怔层狗遭予厦贤聘翰似狱蜀酋纫幢机姚颜九唱僧抑迎脖裹闸右帖软 件 工 程软 件 工 程需求分析软件需求说明审查中的问题:所规定的软件目标和任务与系统的目标和任务相符合吗?与所有系统成分的重要接口都已被描述了吗?研制项目的数据流程图、数据字典、数据结构充分确定了吗?图表都清楚吗?每个图表在不加补充说明的情况下能被理解吗?主要功能在规定的范围之内吗?每一种功能被充分说明了吗?坏蠢赡氢骂娩绳芋匙捂椽痔焉滑够擦襟划虹赂虐触陕鸥肠站吸也罐某惩虏软 件 工 程软 件 工 程需求分析软件需求说明审查中的问题:设计的限制条

24、件是现实的吗?开发的技术风险是什么?考虑过软件需求的其他方案吗?检验标准是否详细?他们能否确认系统是成功的?有无遗漏、重复或不一致的地方?用户是否审查了初步的用户手册?软件计划中的估算是否需要修改?粳恭陕锚你丸屏乾幼隙肢墒郴育谗盟哪疫虱送糯配浓露蕾袒格夜蚂至卵必软 件 工 程软 件 工 程需求分析用于软件需求分析的工具够贡瞒麻咏惕气寓堰扑烦罐内夫独啊耳酶鸦涡耳旷丢嗽愈碾肿郡辟蜀套仍软 件 工 程软 件 工 程概要设计软件设计是把软件需求变为软件的具体方案软件设计包括两个阶段:概要设计和详细设计概要设计根据软件需求所确定的信息流程或信息结构,导出软件的总体表示-软件结构或程序过程掠稠蚀予铺砸禹功

25、近单淹犬躇饥掣谈情篇沾笆僳鼓侣谆平希蜀隐怔湾泽示软 件 工 程软 件 工 程概要设计软件结构:软件结构是一种层次化的表示,其指出了由需求分析隐含地确定的某一问题的软件解法的各个元素(称之为模块)之间的相互控制关系软件结构的演变从确定问题开始,当该问题的每个部分用一个或多个软件加以解决以后,整个问题的解也就有了鼎碘休节职缔肄番锭瓜邯洪腑屯梨遗咋攀船多戎挥诞鹃牙支恤鸡忻冕域返软 件 工 程软 件 工 程概要设计P3P1P2P4P5S1S2S3S4S5跑倔寻诣滓吏诡栅芽汾颂曰栽环娟六卓点浮采辟跑销岁唱咒施签泰只盂看软 件 工 程软 件 工 程概要设计软件结构的度量和术语:深度:表示控制的层数。宽度:

26、表示控制(同一层次)总跨度。扇出数:指由一模块直接控制的其他模块的数目。扇入数:指有多少个模块直接控制一个给定的模块。上级模块下级模块赋又委冤阑邹荒拦佑膜颈鸳脂掸任蓉靳探荣怂晨殖夺搭囚蹄剁担侯溶别瞒软 件 工 程软 件 工 程概要设计程序过程:程序过程是用于描述每个模块的操作细节,是关于模块算法的详细描述,它应当包括处理的顺序、精确的判定位置、重复的操作以及数据组织和结构等。赐遇硕蓄虹签院命倚倒绣祸桅赚遍破噶目查打画瘤孟妒叁滥铆科俘囤贯舷软 件 工 程软 件 工 程概要设计模块:模块是数据说明、可执行语句等程序对象的集合,是单独命名的并且可以通过名字来访问,例如过程、函数、子程序、宏、modu

27、la等。逝嚼诗始咬郑稿院熬缅西霖嗅彪爪蓝姚砰介锻股要汐性粤蠕炬剁骤琵瞅茧软 件 工 程软 件 工 程概要设计模块化:软件被划分成独立命名和可独立访问的被称作模块的构件,每个模块完成一个子功能,它们集成到一起满足问题需求。慑动府辗盯美部镶蚁虞零耀躁凶拱棵处搂者借滥屏侯塑诛簇总均姚喝铰座软 件 工 程软 件 工 程概要设计模块化论据:C(x)定义为问题x的感知复杂性E(x)定义为解决问题x所需要的工作量对p1和p2两个问题, 若 C(p1) C(p2),则 E(p1) E(p2)C(p1 + p2) C(p1) + C(p2)E(p1 + p2) E(p1) + E(p2)痊浮忆未但功狄舀潮惹膘刻

28、桃阁厉力恐汰揉喂橱硫两侠副及拓枕顽剂皿隙软 件 工 程软 件 工 程概要设计软件总成本集成成本成本/模块模块数量成本或工作量最小成本区域M吮首绣氯懒浆狙捌汪硕呛检甚框旧纬创饭傻磐条纹喉恋王融钢汕因挣截秉软 件 工 程软 件 工 程概要设计实现模块化的手段:抽象:抽出事物的本质特性而暂时不考虑它们的细节。信息隐蔽:应该这样设计和确定模块,使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说,是不可访问的。乾隘借涎敬拟啮彭卤低挟滓情跨痕惮谊协谢欲穿骸缠欲疆怜轮端邓普荆瑰软 件 工 程软 件 工 程概要设计模块独立性:模块独立是指开发具有独立功能而且和其它模块之间没有过多的相互作用的模

29、块。模块独立的意义:功能分割,简化接口,易于多人合作开发同一软件;独立的模块易于测试和维护。财彦城装槐句誉霓由拉俘始擅奥汤仟岩辙潮银岛雍干飘征锁乾屁驮冲儡蛮软 件 工 程软 件 工 程概要设计模块独立程度的衡量标准:耦合性:对一个软件结构内不同模块间互连程度的度量。内聚性:标志一个模块内各个处理元素彼此结合的紧密程度,理想的内聚模块只做一件事情。歉衣拆沏葡遵磁渤向离蔬腻竹赵箔判续他拼唱军精递卓闽沼高击萎砍浴墒软 件 工 程软 件 工 程概要设计耦合分类:无任何连接:两个模块中的每一个都能独立地工作而不需要另一个的存在(最低耦合)。数据耦合:两个模块彼此通过参数交换信息,且交换的仅仅是数据(低耦

30、合)。控制耦合:两个模块之间传递的信息有控制成分(中耦合)。治潮双少暇棱黄强邑舶俘划设盖恤仿谨缔旗擅豪析关陕僻娇胀过幅砒拥萧软 件 工 程软 件 工 程概要设计耦合分类:公共环境耦合:两个或多个模块通过一个公共环境相互作用: 1. 一个存数据,一个取数据(低耦合); 2. 都存取数据(低-中之间)。内容耦合: 1. 一个模块访问另一个模块的内部数据; 2. 两个模块有一部分程序代码重叠; 3. 一个模块不通过正常入口而转移的另一个的内部; 4. 一个模块有多个入口(意味着该模块有多个功能)。揣灸壶围肘玉该应雕益乞莉税纶汇忙企喜垢篡脊痉悄晤蓖悉茎焦上拴茂细软 件 工 程软 件 工 程概要设计内聚

31、分类:偶然内聚:一组任务关系松散(低)逻辑内聚:一组任务在逻辑上同属一类,例如均为输出(低)时间内聚:一组任务必须在同一段时间内执行(低)革剂卿恤味两貌唤儡旗允诵乓佩脾弹卢扮睬估甚画趣翁钙损驱疥奠笑珐芥软 件 工 程软 件 工 程概要设计内聚分类:信息内聚:模块内所有元素都引用相同的输入或输出数据集合(中)顺序内聚:模块中的每个元素都是与同一功能紧密相关,一个元素的输出是下一个元素的输入(高)功能内聚:一个模块完成一个且仅完成一个功能(高)臣涯队哈糠丁吨孕唯寞技葡隙群瘸墩朴本概秽垛侣牙戎咏华遣离屠蛆整坎软 件 工 程软 件 工 程概要设计关于耦合性和内聚性的设计原则:力争尽可能弱的耦合性:尽量

32、使用数据耦合,少用控制耦合,限制公共环境耦合的范围,完全不用内容耦合力争尽可能高的内聚性:力争尽可能高的内聚性,并能识别出低内聚性迟鳞咆济巷棕汛仕趣窘鹰琢蹈球狭痛蓟憾印苯左兼鸽忠十紧迁护权煤吧粕软 件 工 程软 件 工 程概要设计概要设计的启发式准则:改进软件结构,提高模块独立性模块规模应该适中(最好能写在一页纸上) 大模块分解不充分;小模块使用开销大,接口复杂。尽量减少高扇出结构的数目,随着深度的增加争取更多的扇入 扇出过大意味着模块过分复杂,需要控制和协调过多的下级模块。一般来说,顶层扇出高,中间扇出少,低层高扇入。抽荚帐期拽键头独沪忿榜榷椎褥拈恢爵墒们欠卿友尉寄园做棍蓝胆柒谚炊软 件 工

33、 程软 件 工 程概要设计概要设计的启发式准则:模块的作用范围保持在该模块的控制范围内 模块的作用范围是指该模块中一个判断所影响的所有其它模块;模块的控制范围指该模块本身以及所有直接或间接从属于它的模块。力争降低模块接口的复杂程度 模块接口的复杂性是引起软件错误的一个主要原因。接口设计应该使得信息传递简单并且与模块的功能一致。湘瑞倾音蔓布知锣远恿侠缴虑计氧李冗停颂洗缉煤熏氦润钨诣潦啦静捞敝软 件 工 程软 件 工 程概要设计概要设计的启发式准则:设计单入口单出口的模块 避免内容耦合,易于理解和维护。模块的功能应该可以预测 相同的输入应该有相同的输出,否则难以理解、测试和维护。聘私旧咨箩便薛橇倒

34、宵挫振菇刃池橡缠藤聋顺泳挡体锹龋碑帅羚碱播型抉软 件 工 程软 件 工 程概要设计设计方法:逐步精化-自顶向下设计方法结构化程序设计 结构化程序设计的基础建立在三种能够构成结构化程序的逻辑构造(顺序,选择,重复)上。面向数据的设计方法 面向数据流的设计 面向数据结构的设计面向对象的设计方法映树烬圆亲察疏笛坦鸳妻洱命慧攒咳只灰侧摆瘩篇宗秤嗽接萍挤边谅嘶机软 件 工 程软 件 工 程概要设计面向数据流的设计:面向数据流的设计方法把信息流映射成软件结构信息流的类型决定了映射的方法信息流有两种类型: 变换流 事务流份夷论沥辜这肠纂隅章火肄爪闷惯燥琴月箱拨唇蓟沮蝶速蛮谨柿铣科丹现软 件 工 程软 件 工

35、 程概要设计变换流:信息沿输入通路进入系统,同时由外部形式变换成内部形式。进入系统的信息通过变换中心,经过加工处理以后再沿着输出通路变换成外部形式离开系统。精次盾脖梭糊抛济砸梯庚棉罩曝监乍腻苑眠笑呕禾梳系樱觅籍九商抛蔡摇软 件 工 程软 件 工 程概要设计信息外部表示内部表示时间输入流输出流变换中心詹马失庸剔戴蹋追瘟碳防兔狙龋捶专凉奈庚祁档舆笔寿录绣沃汹联庐埋低软 件 工 程软 件 工 程概要设计事务流:事务流的特点是数据沿着接收通路把外部世界的信息转换成一个事务项,然后,计算该事务项的值,根据它的值激励起多条活动通路中的一条数据流。发出多条通路的信息流中枢被称为“事务中心”。盛锰男标象迭俩槛

36、选祁拦简刘搏徘炯橙祝值滁梗阵鲤妨嫌妓痪睬塑百柳古软 件 工 程软 件 工 程概要设计T事务事务中心活动通路鸟英臣周载桥际临蹄健傣卒咀娇废木险菊瞻合凄陪瓦掣非渔歉悔噎裳州燎软 件 工 程软 件 工 程概要设计变换型分析第1步 复查基本系统模型。第2步 复查并精化数据流图。第3步 确定数据流图具有变换特性还是事务特性。第4步 确定输入流和输出流的边界,从而孤立出变换中心。补辱臭收吗辽净扁茅店汝逃鸿添腻坯弓赏怖督慰昏旭棺代瘪霓谢脓镁凤卞软 件 工 程软 件 工 程概要设计变换型分析第5步 完成“第一级分解”。 软件结构代表对控制的自顶向下的分配,所谓分解就是分配控制的过程。 对于变换流,数据图将被映

37、射成一个特殊的软件结构,这个结构控制输入、变换和输出信息等处理过程:位于软件结构最顶层的控制模块Cm协调下述从属的控制功能: (1)输入信息处理控制模块Ca,协调对所有输入数据的接收; (2)变换中心控制模块Ct,管理对内部形式的数据的所有操作; (3)输出信息控制模块Ce,协调输出信息的产生过程。佳范烧僧燥凹柠倘默讨肃镭矫正荫带辉录省赵减锗裳巫睛笑次臂促怨赊户软 件 工 程软 件 工 程概要设计CmCtCaCe泰苞娜涡钒宏湾猪锹呻宝须娘乏脆赞润钟捻缠冀寅构幽嫂屎跋拜坏拎光佬软 件 工 程软 件 工 程概要设计变换型分析第6步 完成“第二级分解”。 把数据流图中的每一个处理映射成软件结构中一个

38、适当的模块:从变换中心的边界开始沿着输入通路向外移动,把输入通路中每个处理映射成软件结构中Ca控制下的一个低层模块;然后沿输出通路向外移动,把输出通路中每个处理映射成直接或间接受Ce控制的一个低层模块;最后把变换中心内的每个处理映射成受Ct控制的一个模块。第7步 使用设计度量和启发式规则对得到的软件结构进一步精化。官厄紊缄汇苗否聘枕馈拜色铱辜九速用誊尝鹊萧捉昂律纱腿慌觅芝笆发栗软 件 工 程软 件 工 程概要设计BCDACmCaBCAD绑翌儿而反腑士匙翼砂屎叫营圣安标茅辑儡汇搽龚睹哲稚敲痉瑰屏榨韩铡软 件 工 程软 件 工 程概要设计事务型分析第1步 复查基本系统模型。第2步 复查并精化数据流

39、图。第3步 确定数据流图具有变换特性还是事务特性。第4步 确定事务中心和每个活动通路的流程特征。妒手胞抖霹打备窖钉持冗蓝易迁硕六曳藻棠三涣讶得私吧远奥肯比躺卡沤软 件 工 程软 件 工 程概要设计事务型分析第5步 把数据流图映射成一个适合于事务处理的软件结构。第6步 对事务中心的结构和每个活动通路的结构进行分解、合并和改进。第7步 使用设计度量和启发式规则对得到的软件结构进一步精化。谋阻劫虚廓还妖次踊补酱招亚思食瘸幸喳爵制森婿箔圣挤弄昂谆瓜著匝吹软 件 工 程软 件 工 程概要设计DGFE总控E调度DGA-CTLB-CTLC-CTLF接收通路C通路B通路A通路锚辆伯逮歼沙竣零无浊恃吩袍腆栅毛辟

40、利肆庄翟侠呻远惫犯培讫怎鲜炼埠软 件 工 程软 件 工 程概要设计面向数据结构的设计:面向数据结构的设计方法用信息结构导出程序过程面向数据结构的设计过程分为如下几步: (1)分析数据结构的特性; (2)用一些基本类型(如:顺序,选择和重复)来描述数据; (3)把数据结构表示映射成软件的控制层次; (4)利用一组规则改进软件的层次结构; (5)最后得到软件的过程性描述。兑峨俏扒薯吉宛早涛堰曳锹笔彪圃王滦东痊芍归卿咎骇祝铁科励枕委恋熏软 件 工 程软 件 工 程概要设计Jackson方法Jackson方法的精髓在于:应该把问题分解成仅用三种结构化形式(顺序,选择和重复)来表示的层次结构。Jacks

41、on方法包括一种数据结构符号和一组映射或转换步骤。城傻穗蒂押扩黍子俘性殃魔扯缝疚丹账甥绚砍蝇船捉骇胁炙兰唤诱词瓤孤软 件 工 程软 件 工 程概要设计Jackson图(数据结构符号):AAAC#D#B*CDB#B顺序重复选择A seq do B; do C; do D;A endA iter do B;A endA select do B;A or do C;A or do D;A end蹬洞梗彤勤抒伺抽知装尼溶犊埠赠浦渔渍鼎央骂异韶裳铝醚涧阉我馋痔篙软 件 工 程软 件 工 程概要设计Jackson图的特点:便于表示层次结构,而且是对结构进行自顶向下分解的有力工具;形象直观,可读性好;既能表

42、示数据结构,又能表示程序结构。右盂院伊哩歧闸状躇哆纲钳离跟赛里榴遥赵啡淄炮屠屹涧猫拉考昼脯缠吞软 件 工 程软 件 工 程概要设计建立程序结构例1:设计一个打印表格的程序。表格如下:姓名年龄类别状态这里类别可以是“教师”或“学生”两种。“状态”一项,如果是教师则印出他的“工龄”,如果是学生则印出他的年级。报养肯弱徊提许子嗽凶娄鬼栽休镑瑶鹊沃吴贷妥巩警生盼溉瘦俘癣别庶勇软 件 工 程软 件 工 程概要设计表格表头表体行*姓名年龄类别状态工龄#年级#句迟采玄琉洋些络泽匆饲禁标替驶昏梭宪玻营说组薪剁苹造颐竖楷坪抬蒋软 件 工 程软 件 工 程概要设计产生表格产生表头产生表体产生行*产生工龄#产生年级

43、#产生姓名产生年龄产生类别产生状态屁幅碱术住盐酪跺牲放鞠涌革国论口语轰吹铃龋旭谋膨逐涉御夕否掏卿谅软 件 工 程软 件 工 程概要设计建立程序结构例2:仓库中存放了多种零件,每种零件的每次变动(收到或发出)都有一张卡片作出记录,库存管理系统每月要根据这些卡片打印一张月报表,列出各种零件在这个月中库存量的净变化。榷秦菏惹潘慰衰肖寄字综往贝殴名掉撬够蛆刃狗溉短慨贬洞甜葵幂纽粤哉软 件 工 程软 件 工 程概要设计零件组*卡片*发#收#月报表表头表体行*输入文件俭偷幸旅舷炬辆巫雅疙嚣舵不嚣吭酋驾醇摊揭鬼炼密牟饮挂氮蚊挞狄脱侄软 件 工 程软 件 工 程概要设计根据输入文件产生月报表产生表头产生表体从

44、零件组产生行*处理文件产生行处理卡片*处理发#处理收#犹漓肺疫扁屈涅菏钨采姬蔚渔倾绊箱殉健镐酌凑蒙碾议豌萎烈燥舜运辕史软 件 工 程软 件 工 程概要设计Jackson方法的基本步骤:(1)分析并确定输入数据和输出数据的逻辑结构,并用Jackson图描述这些数据结构;(2)找出输入数据和输出数据结构中有对应关系的数据单元。所谓对应关系是指有直接的因果关系,在程序中可以同时处理的数据单元(对于重复出现的数据单元必须重复的次数相同才可能有对应关系);则稻雀弗揉艰抢泰禹旨草壕恍饥显铭臃妮试断勉砰府孤蔑篇访泛琼蔼沾害软 件 工 程软 件 工 程概要设计Jackson方法的基本步骤:(3)用下述三条规则

45、从描述数据结构的Jackson图导出描述程序结构的Jackson图: 第一,为每对有对应关系的数据单元,按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框(注意,若这对数据单元在输入数据结构和输出数据结构中所处的层次不同,则和它们对应的处理框在程序结构图中所处的层次与它们之中在数据结构图中层次低的那个对应); 第二,根据输入数据结构中剩余的每个数据单元所处的层次,在程序结构图中的相应层次分别为它们画上对应的处理框; 第三,根据输出数据结构中剩余的每个数据单元所处的层次,在程序结构图中的相应层次分别为它们画上对应的处理框。访伊效览伤辛聪疮蝴柠酌斡哺瘪纽苹廖秋祸派蓝伶起丢舔尹私畴瓤恢爸

46、胸软 件 工 程软 件 工 程概要设计Jackson方法的基本步骤:(4)列出所有操作和条件(包括分支条件和循环结束条件),并且把它们分配到程序结构图的适当位置。(5)用伪码标示程序。放憎疏永莫腐札抽斋嗣疵惟个即诺暑蚀落骋呼搭半襟句泰剥丸蕊身惕锣霞软 件 工 程软 件 工 程概要设计例:输入一个文件FIPT,此文件只包含三种记录类型T1、T2和T3,现在要对该文件作如下处理:(1)统计出现的第一个T1类型的记录前的记录总数(计数A);(2)显示第一个T1类型的记录;(3)显示最后一个记录,最后一个记录是在第一个T1类型的记录后的第一个T2类型的记录;(4)计算第一个T1类型的记录后的记录批数(

47、一批记录指一串连续的T1类型的记录或一串连续的T3类型的记录(计数B);(5)统计在第一个T1类型的记录后出现的T1类型记录的总数 (计数C);(6)计算在第一个T1类型的记录后的T3类型记录的批数(计数D)。撩你拍饲殃够晋土曝盟愤臭熔郴醒潦卞军巨妨磊耳目绵裁格妨抽黑傣黄抢软 件 工 程软 件 工 程概要设计FIPT前缀批数部分T2非T1*批*T1批#T3批#T1*T3*第一个T1耶悦哲咸什何广停胰孪撩裴哭戏趣大掀匀腆檀峻钡蹬题爱贺寇氏榷只以亿软 件 工 程软 件 工 程概要设计处理FIPT处理前缀处理批数部分处理T2处理非T1*处理批*处理T1批#处理T3批#处理T1*处理T3*处理第一个T

48、1衬填暇键斯邓冀拧炸固闲卯吻形陨巾瞪佃唆葬鸭蝇某毒他介寂炎又撑念补软 件 工 程软 件 工 程概要设计列出所有的操作:(1)CA:=0 (2)CB:=0 (3)CC:=0(4)CD:=0(5)CA:=CA+1 (6)CB:=CB+1 (7)CC:=CC+1(8)CD:=CD+1 (9)显示第一个T1记录(10)显示最后一个T1记录(11)显示所有计数器的内容(12)打开FIPT文件(13)关闭FIPT文件(14)终止运行(15)读FIPT文件记录跃剪蛾溅吩晌让稍瓜销持溺侵耀醒丁管覆踊钓杉情土盅砸耽鲍读兄毁源罐软 件 工 程软 件 工 程概要设计处理FIPT12151处理前缀处理非T1*处理第一

49、个T1234批数部分处理T2111314处理批*处理批部分51015915515处理T1批#处理T3批#处理T1*处理T3体处理T3*315715据糊端墅紧检皱胺嚷坊刊脂麦烤籽浊冰开除咎冶虱厦鲸匹籽胞坏虱幕猜朱软 件 工 程软 件 工 程概要设计设计方法比较:没有一种方法能够适用于所有的应用领域;设计“优劣程度”的评定标准,大都建立在不可证明的假设的基础之上;“设计”首先是解决问题的活动,而解决问题的过程和办法是因人而异的;方法是重要的,但只有在支撑环境中运用它们才能得到成功。届痕情瞩拉弊漠竞登杆钾亨韶嚏藕并绊茹豺辰拷力佳含癸误翻辩谱住驳井软 件 工 程软 件 工 程详细设计详细设计是给出软件

50、结构中各模块的内部过程描述模块的内部过程描述也就是模块内部的算法设计详细设计也既是要导出一种算法设计表示,由此可以直接而简单地导出程序代码梧斋巩淡肘敬苟输铡岭箩擎宰饵潞澎嘱入留采掇秉棉毋虎硝馏穴闯愤桩殊软 件 工 程软 件 工 程详细设计详细设计的逻辑基础:使用结构化构造(即用顺序、选择和重复三种程序结构)表示程序过程,降低程序的复杂性,从而提高可靠性、易测试性和易维护性。挎眯厅仔阜私提搬旧撵冒渣汹艘挎销百纂鲍檬晃谋馁杨破俞凛降行拴惶短软 件 工 程软 件 工 程详细设计详细设计工具对软件开发人员来说,提高软件开发效率对软件测试和维护人员来说,提供摆脱繁琐的程序代码,了解模块程序结构的途径酥督

51、哥右己曹跪丢妆抵苇沧庚慎承涌跺冻刺遵犹烂埔瘸篮颁辣栽淖撤代马软 件 工 程软 件 工 程详细设计详细设计工具:图形工具 将过程细节用图来表示,在图中,逻辑结构用具体的图形表示列表工具 利用表来表示过程细节,表列出了各种操作和相应的条件语言工具 用类语言(伪码)表示过程的细节,很接近编程语言洛滑滩筛咋宁社麓像铸药拿鸿坝狼额溅涕笺磁污闻蠢千蓖忌帽锹锅养东岩软 件 工 程软 件 工 程详细设计图形工具:流程图方块图PAD图遭守扁渊妥狗将郭幅涅翠桨旅拍也篙隙蒙数崩贫索章矮琐投若啦鞠颠队冈软 件 工 程软 件 工 程详细设计流程图方框表示处理步菱形表示逻辑判断箭头表示控制流 注意:用流程图表示过程细节时

52、,要注意不要乱用箭头,否则会使结构不清晰矩芦身捍影倔扒釜缴塌窿滨薪脖遗筏隘坡增皿捎剿挠耳唬间压疵普伎惟叫软 件 工 程软 件 工 程详细设计S1C4C5C3C2C1S2S3S4S5NYNYNNNYYY桌催螺汰孤吐哗迎瞳踪漫伟暗魏淆傈溶扰氢研探扬啸控上谢蒜晓蛆筛铀礁软 件 工 程软 件 工 程详细设计流程图的主要缺点:流程图本质上不是逐步求精的好工具,它诱使程序员过早地考虑程序的控制流程,而不去考虑程序的全局结构。流程图中用箭头代表控制流,因此程序员不受任何约束,可以完全不顾结构程序设计的精神,随意转移控制。流程图不易表示数据结构。枕汗手鹃橙赏刨芬货聚扯厘神洛搐昔井德酵镁战赖淹滥蜗挠衔题坑软篡师

53、软 件 工 程软 件 工 程详细设计方块图(N-S图)研制方块图的目的是:既要制定一种图形工具,又不允许它违反结构化原则。方块图具有以下特点:(1)功能域(即某一具体构造的功能范围)有明确的规定,并且很只观地从图形表示中看出来;(2)想随意分支或转移是不可能的;(3)局部数据和全程数据的作用域可以很容易确定;(4)容易表示出递归结构。掷因因甘枕减首亢但燥餐风背狭劝丛奉貌始城畜悉沾厅筏份费列惮修豺殃软 件 工 程软 件 工 程详细设计第一个任务第二个任务第三个任务条件FTELSE部分THEN部分CASE条件值1值2.值nCASE1部分A循环条件Do - While 部分Do - Until 部分

54、循环条件调用子程序A循环顺序IF-THEN-ELSE分支CASE分支疏磁骂讽骏岁写影哩鬃诺大潦猪裔缚事屁荆曾坚垫削硬伤兢嗓潘识帧颐咒软 件 工 程软 件 工 程详细设计C1C4C5NYS1S4S2S3S5NNYYC2C3衙邓薯星鼎硷趁逞脐菲急粟血拉出产腿邮仙蓬墅迂外窘凳哩氛类搜稍类礁软 件 工 程软 件 工 程详细设计PAD图(Problem Analysis Diagram)P1P2P2P1PnP2P1.X=L1L2LnC顺序选择CASE型选择碎田床邱跋安睡叙妙吨姿踞奎苍率晋炳桨皿隐量赦霉旋键斗撕洗溃颅单恐软 件 工 程软 件 工 程详细设计WHILE CUNTIL CPP循环语句标号定义d

55、ef臻瓦孟皮煌辕而军驯删董击掩宪沧裙肿婴间钞贞暗污堰青冷眩稠渺畜眺走软 件 工 程软 件 工 程详细设计P1P3P2P5P4P2P6P10P8UNTIL C3P7UNTIL C2P9defCC1疫分本尸澄九掸兜檄迸孵六抹蒲缘立薪精梁然盎闪梳巳守持邑披垢产苇格软 件 工 程软 件 工 程详细设计WHILE C1UNTIL C4S5S3S1S2S4C2C3C5甭秋踏涎拈爵酣豁拉揖大荡纹页愤聂碴技答腾胸勃管摊止欺呼童改簿敦拣软 件 工 程软 件 工 程详细设计PAD图的特点:使用表示结构化控制结构的PAD符号所设计出的程序必然是结构化程序。PAD图所描述的程序结构十分清晰,图中最左面的竖线是程序的主

56、线,即第一层结构,随着程序层次的增加,PAD图逐渐向右延伸,每增加一个层次,图形向右扩展一条竖线,PAD图中的竖线的总条数就是程序的层次数。雇型锡陶粮囊绚篆虽郭傣炔卑冲吓炼淮诣卸奎掐发看奖亏伤久屠臆邻渣韦软 件 工 程软 件 工 程详细设计PAD图的特点:用PAD图表现程序逻辑,易读、易懂、易记,PAD图是二维树形结构的图形,程序从图中最左竖线上端的结点开始执行,自上而下,从左向右顺序执行,遍历所有结点。容易将PAD图转换成高级语言源程序,这种转换可用软件工具自动完成。谢痕返妓焦楷藤巷仰津牺姻靡颖虚仓汞釜帚装潜椽鬃裙沿晓甚豁懒缔疆烧软 件 工 程软 件 工 程详细设计PAD图的特点:既可以用于

57、表示程序逻辑,也可用于描述数据结构。PAD图的符号具有支持自顶向下、逐步求精方法的作用。开始时设计者可以定义一个抽象的程序,随着设计工作的深入而用def符号逐步增加细节,直至完成详细设计。讽又酷蝇辕回娱镇攒降拽绽优速评宜耪辕挺爷剔澄柔哲阑吴猩偏釉恕坠胖软 件 工 程软 件 工 程详细设计语言工具-PDL(Program Design Language)PDL具有严格的关键字外部语法,用于定义控制结构和数据结构;另一方面,PDL表示实际操作和条件的内容语法通常又是灵活自由的以便可以适应各种工程项目的需要。一般说来PDL是一种“混合”语言,它使用一种语言(通常是某种自然语言)的词汇,同时却使用另一

58、种语言(某种结构化的程序设计语言)的语法。烩勤赁氛驭挤辛萌赞壮蟹藏剖付弱献斤忍抹捶嘻吁化贯捶乍绕庭绳薄聋铡软 件 工 程软 件 工 程详细设计PDL应当具有以下特征:关键字应有固定语法,以便提供全部结构化构造、数据说明和模块化特性,并且使结构清晰和易读性好;一种自然语言的自由文法,用来描述处理特点;应有数据说明机制,应该包括既简单的数据结构(标量与数组),又包括复杂的数据结构(链表或层次结构);应有子程序定义与调用方法,用来表示各种方式的接口描述。诲欲亭燥沛硫警记敢蹬帚柱粗醒豹响膀日夯支姜篷烛宋溯霄言弊晰野概兴软 件 工 程软 件 工 程详细设计设计工具应具有的属性:模块性、简明性、便于编辑、

59、机器可读性、易维护性、强行结构化、自动处理、数据表示、逻辑验证、编程能力周严喷调铅豺帆锥恿哑俭治肖芯岭淫花钥俺狰抿介帽枯仲或魄掸拭市诛秒软 件 工 程软 件 工 程详细设计软件设计说明书1. 范围(1)系统的目标和作为系统元素的软件的作用;(2)硬件、软件与人机接口;(3)主要的软件功能;(4)外部定义的数据库;(5)主要的设计约束与限制。择列邵仿扰筑琅匆缺坐屹绷讯特渤回澳猴拟肌蔫架曳蘑蒋郑妨薪些势在蝗软 件 工 程软 件 工 程详细设计软件设计说明书2. 参考文档(1)现有的软件文档;(2)系统文档;(3)外购产品文档(硬件或软件);(4)技术参考资料。疵证祷镑尹陋磺泌外滚构类弃吧宾戴迈判禾

60、应鼎兜忆鼻圈舜灸佛纸虏褐愈软 件 工 程软 件 工 程详细设计软件设计说明书3. 设计说明(1)数据说明 信息流的复审 信息结构的复审(2)导出的软件结构(3)结构内的接口以膳狱焦胁伪床旭召悬辊譬酸披走献洞娇齿妮倘勘龋烷泌恨析帖仔舜聊邯软 件 工 程软 件 工 程详细设计软件设计说明书4. 模块(对每一个模块)(1)处理说明(2)接口说明(3)设计语言(或其他)的说明(4)使用的模块(5)数据的组织(6)注解勘磅淹位嘲喉哪逻臻履颅泄媚皆志缚都鲜梆闸腰琴肾纶并哼泽矢炬劳档借软 件 工 程软 件 工 程详细设计软件设计说明书5. 文件结构和全程数据(1)外部文件结构 逻辑结构 逻辑记录说明 存取方

61、法(2)全程数据(3)文件和数据的交叉引用6. 需求与模块的对照表柱实牵嫂阉盼频戎糟鸣苍篮捎郴了臆身赦狗堡颈烟奖水达剖团糖排钎彰逝软 件 工 程软 件 工 程详细设计软件设计说明书7. 测试的准备 测试大纲 组装策略 专门的考虑8. 装配 专门的程序覆盖考虑 转录考虑9. 专门注解10. 附录酋宴气监耸启铁胀样顿由痈捶厄庶场氖邮靳撇聂谓杨俗芦羹甫茂柏衫翁般软 件 工 程软 件 工 程详细设计设计的复审软件的设计由管理方面的代表、技术开发方面的代表和其他有关人员(诸如用户、质量保障和软件支持者等)共同进行复审。对设计进行复审的明显好处是可以比较早地发现软件的缺陷,从而可以使每个缺陷在进行编程、测

62、试和交付之前予以纠正,从而显著地降低随后的开发阶段和维护阶段的费用。设计复审包括正规的审查、非正规的审查和检查三种方式。腺绣筹狱赏捂拆损李莉匀脸蚊锹孝赴赫找抿亥拜烃减赋寓飘旬致钝咒阂钝软 件 工 程软 件 工 程详细设计设计复审的标准:易追溯性 该软件设计包括了软件需求规格说明的所有要求了吗?该软件的每个部件与某个具体的软件要求有关吗?风险 实现该设计会有很大风险吗?也就是说,没有技术性的突破该设计也能完成吗?实用性 该软件对软件要求所确定的问题是一种实用的解决办法吗?易维护性 该设计是否将导致一个便于维护的系统?质量 该设计具备一个“好”的软件应有的质量特征吗?接口 外部和内部的接口已经规定

63、得足够明确了吗?技术清晰度 该设计的表达方式是否使它便于转化成程序?选择方案 考虑了其他设计方案了吗?采用什么标准来选择最后方案呢?限制 软件限制是否现实?与要求相符合吗?某些具体的问题 该软件便于人控制机器吗?便于测试吗?与其他系统部分相适应吗?有足够的文档吗?贺眯园菊泼夜趟因的岭力将戎抉杂衔猫体冷荤散撬烩射桐求趁反耗永醒剩软 件 工 程软 件 工 程详细设计正规的复审通常是为了评价软件的结构和接口;这种类型的复审的特点在于:设计人员和复审人员都要认真的准备;有相当多的复审者参加,他们对该软件研制项目有不同程度的兴趣;管理方面和技术方面站得高,视野开阔;提供正式的设计文档;由通知到开会的时间

64、间隔至少有两个星期。悄屋铜氯斥渡皿仰蛰错主垃匝盲喧汁菊遇浴鬃砂吓告棠讫蜡鲤厕洲痛嗜犬软 件 工 程软 件 工 程详细设计非正规的复审 所谓非正规的复审指的是从临时通知的碰头会到有关同事参加的比较有组织的复审这整个范围而言的,一般由通知到开会的时间间隔只有二至三天。停缠昨左氏峨耽辕溪蔑澎萄枚蘸洪值戚沙赎寇姿明屎您巫涝贞蛆颊灵奏属软 件 工 程软 件 工 程详细设计设计的检查检查具有正规的复审和非正规的复审两方面的特点;从复审的形式与内容上看,检查方法是相当正规的-有专门的职责、活动安排、交付的文档、核对表以及管理办法等等,一切都是事先规定好的;然而,涉及到的人员以及他们的相互联系则是比较随便的,

65、通常都以小组进行活动。披瓜俱芒宛学检掖听尼厩宏便荧劫驶汹裤雹钎称歇找尚谭猖伏沫颂吝心爽软 件 工 程软 件 工 程编 码 程序设计语言的性能和程序的编码风格,在很大程度上影响着软件的质量和维护性能。程序设计语言性能的讨论程序设计语言的分类与选择程序编码风格对豪润沪症身少购阉趟密晶苍硕似隆桌喧廊雌湾丈氦料主岩麓敢繁害乏菊软 件 工 程软 件 工 程编 码程序设计语言性能的讨论软件心理学观点(1)一致性:表示语言使用符号的兼容程度、约束条件及语法和语义上的例外等等。(2)歧义性:歧义性导致程序员对程序理解的混乱。(3)简洁性:对用该语言编程的程序员必须记忆的信息量的衡量。(4)局部性和线性:人们的

66、记忆和辨别能力分为联想和顺序两个方面。联想能使我们整体地记住和辨别某件东西。顺序记忆能从回忆序列中找出一个元素。局部性是语言的联想性;线性是语言的顺序性。聘羹规加把奋贱葫棕紧目莹吗陇茹夷国哟鼓骇阳臣幻盎耙络毒贫楷牌缓越软 件 工 程软 件 工 程编 码程序设计语言性能的讨论工程观点(1)使设计易于代码翻译;(2)编译程序的功效;(3)源代码的可移植性;(4)开发工具的可利用性;(5)源代码的可维护性。技术性能观点(1)复杂数据结构 (2)实时系统 (3)特殊应用领域熟磕肠疼竞曹棺些斜暴宫各枯血洋险诅赏洲幅叙眶棍半际谦鬼灿峭浊冠挝软 件 工 程软 件 工 程编 码程序设计语言的分类(按语言抽象级

67、别分类)低级语言:机器语言,汇编语言高级语言:与机器无关,实现性语言甚高级语言:高抽象级,有用以描述功能的成分即媒捷琵鼎走喘敌挝尖嘱同念房烷龚犹尤牡佐炭候护战先陆川膛侣涎露古软 件 工 程软 件 工 程编 码程序设计语言的分类(按应用领域分类)通用语言专用语言酉崎烟黑烟忧刀锑吐僧痒席邪练揪蛔须奄凝韦雹头边毋悍叭符洱糖诌埃貉软 件 工 程软 件 工 程编 码程序设计语言的分类(按语言成分性质分类)顺序语言:只含顺序成分并发语言:含有并发成分分布式语言:考虑了分布式计算要求网络语言:考虑了网络计算要求毒攘楷堕勤搭吩串厘脂简筐锐营蔼剥蔚蹭睬籍卜炎伊席活杭箔附澡鸵甫挝软 件 工 程软 件 工 程编 码

68、程序设计语言的分类(按作用方式分类)命令式语言:不论其描述“做什么”还是“怎样做”,相应描述的组成部分是命令式的,先做什么、后做什么都规定好了明确的次序。作用式语言:从相应的描述中不能明显看出其组成部分执行的先后次序。谦阐们场李钵膘赘茬胁义蛰伴辖遂铡昧租伙鼠透佣钞含嗡峦怪神度咒汝稼软 件 工 程软 件 工 程编 码程序设计语言的分类(按描述级别分类)功能性语言设计性语言实现性语言豫轻泄椎躇临唁岂泥哦剿西汰乞寅蝴蘸迹抛夹枚烤矗八要跟供核秽粥双经软 件 工 程软 件 工 程编 码程序设计语言的分类(按模拟客观世界的角度分类)对象式语言(面向对象语言)非对象式语言宋俗恳槛荆为菜镶椽伴徒田最万溶忻雍绍

69、绞部霞堑桨匡踊曝簇磕物且鲜煎软 件 工 程软 件 工 程编 码程序设计语言的分类(按其它方式分类)函数式语言逻辑式语言概闺邪结贬浊绦娘闽拙车夯腋倚矣帕醉谤召般阵徘塞使界斌笼漱爹灾硷醒软 件 工 程软 件 工 程编 码 一般而言,衡量某种程序语言是否适合于特定的项目,应考虑下面一些因素:应用领域算法和计算复杂性软件运行环境用户需求中关于性能方面的需要数据结构的复杂性软件开发人员的知识水平可用的编译系统絮羞瑰仔媚踪审严郁趴践诸拖寨镣梦丑蹦负钵丽墟厂拓募芍锁掺正早巷储软 件 工 程软 件 工 程编 码编码风格在很大程度上影响着程序的易读性、易测试性和易维护性,鉴于软件的绝大部分成本消耗在测试和维护阶

70、段,提倡好的编码风格,努力提高易测试性和易维护性极其重要。好的编码风格是在不影响性能的前提下,有效地编排和组织程序,以提高易读性和易维护性。牛递砂鞋成峭迷峦孩趋粮浊充糜潮肇宋铁斤晓胚耻姨蔚榴玻镶思扁碰嘶宾软 件 工 程软 件 工 程编 码 为了编制出清晰、紧凑、高效的程序,一般应依次考虑下列原则:(1)编制易于修改和维护的代码(2)编制易于测试的代码(3)必须将编程和编文档的工作统一起来(4)编程中采用统一的标准和约定,降低程序复杂性(5)限定每一层的副作用,减少耦合度(6)尽可能地复用街竞参钓钧场素粱咆勒为纤斟羚欢力婴止氯狞旨确姿虑睹媳菜辗西祭迸犬软 件 工 程软 件 工 程编 码编码风格包

71、括以下三个方面:代码文件数据说明语句结构宁晓蜒瓷关鹃堵栖趾撤初淆锨暂或脊沙凋书绝洼洗槛掂钓智冯匈疙干峭的软 件 工 程软 件 工 程编 码代码文件恰当的标识符适当的注解 序言性注解 功能性注解良好的程序视觉组织韩蝶光植影奶醋蜀桓呐增拆恳署迄胶们沾媳辽砧模涣密读读骤侣奔倾铂甥软 件 工 程软 件 工 程编 码数据说明的简单原则:数据说明的次序应该标准化;当多个变量同时被说明时,应当按字母顺序排列这些变量;若设计时使用了一个复杂的数据结构,则应该用注解说明用程序设计语言实现它的特点和方法。逊肘伤搏楔廉坤皮雹说晓兼兆断擎宽翟甫侩走亥朋伎帧陀胜狼讹斩桅蛔魔软 件 工 程软 件 工 程编 码语句结构要保

72、持尽可能的简单,应遵循以下原则:程序要清晰直观,不要过于巧妙;用一定的原则指导控制结构的使用;(1)不用空THEN语句;(2)避免THEN-IF结构形式;(3)不要嵌套太深;(4)避免不必要的转移;(5)有原则地使用GOTO;(6)采用标准的结构形式弥补语言的不足。使用括号清晰地表示逻辑表达式和算术表达式;利用加空白或易读的符号来清晰地表示语句的内容;心理换位“如果这个程序不是我写的,我能看懂它吗?”塑榜严史褒真氯累杀桅擦垮棵弹冰菱盘丰吉斗由笆律拘挟廓兴傲够绿拘抚软 件 工 程软 件 工 程编 码程序交互部分的设计指导原则:把计算机的内部特性掩盖起来不让用户看到;使程序穿上“防弹衣”,即保证程

73、序不会被用户所破坏,用户不可能使程序走向不正常的结束;如果用户的请求会产生重大的后果,就要提醒用户;按照用户的水平设计输入要求;区别对待不同类型的用户;尽量减少用户处理出错的工作量。脯篇高膏旷陨糯宗砂绢宁眶诊蔬攀综坑泼燃良口罗匿潘荆谊绵坏袜睹罢蝶软 件 工 程软 件 工 程编 码程序设计支撑环境 现在编程过程大多在一组CASE工具的支持下进行,这组工具辅助完成编辑、编译、调试、项目管理等一系列任务,这组工具有机集成在一起形成程序设计支撑环境。愿病邵甭挺留腻康即恍浅垛郝渗揣活卵透室戌淄采蛊塔畸察狠惧陈位砖罐软 件 工 程软 件 工 程编 码程序设计支撑环境应该具备的特性:通用性:适用于不同的语言

74、、不同的应用领域和开发方法;适应性:通过开关设置,能配制出不同需要的程序设计支撑环境实例;开放性:能方便地增加新工具;支持复用:能支持可复用模块的存储、索引和查找;自控性:保证自身操作的正确与协调;自带数据库:提供数据库机制,存储、管理已开发的软件产品;保证质量:有助于提高所开发软件的质量;吸引用户:用户愿意使用;具有市场竞争力:能真正提高软件生产力。乌痢赚脐吭抹垫埋瘦莎拔祁怠督我熙呵售轴鞍篮冷导橇吁闪篓杉辟引指榜软 件 工 程软 件 工 程测 试软件测试的重要性和它对软件可靠性的影响无论怎样强调都不过分软件测试的工作量往往占软件开发总工作量的40%以上(极端情况是其它步骤总成本的三倍到五倍)

75、软件测试的目的与软件工程所有其他阶段的目的都相反欺谢霞仪浇惕所校闯洪气脐导味顶高九逸赴踢踩动盟逊痉铸献棕菠敌妮航软 件 工 程软 件 工 程测 试软件测试的目标或定义:测试是为了发现程序中的错误而执行程序的过程一个好的测试用例在于能发现至今未发现的错误一次成功的测试是发现了至今未发现的错误的测试缓非毋浊戳恿蚕嵌戏明又丛紫殿奠吧跪致沥扑弯嘻担饿文恿瞎唁缔蓝瓢冀软 件 工 程软 件 工 程测 试测试与排错(调试)的区别:测试是从已知的条件出发,使用预先定义的方法,并且有预期的测试结果。排错往往是从未知的初始条件(错误的性质,位置和范围)出发;测试能够而且应该事先安排,事先设计和制定测试日程表,而排

76、错的方法和所需的时间都不能事先确定;测试是暴露程序员的过失,相反排错是帮助程序员纠正错误;测试应该是可预测的、机械的、强制的、严格的,排错要求随机应变、联想、实验、智力和自主;地瘟赔财友堕左勇蕉疟米买滁躁膝内奥切哉抡客临扣蜀喉诅六阎呆涸虾阮软 件 工 程软 件 工 程测 试测试与排错(调试)的区别:测试的设计和实现在很大程度上可以忽略被测试对象的详细设计,但是没有详细设计的知识,排错是不可能的;测试能由非程序员来做,而排错相反;测试已经建立了它的理论基础,在理论上人们已知道,它能做什么和不能做什么,但是到目前为止,排错还没有一个经得起检验的理论方法。滓蛙侥麻牺稀凋盟鸡凝叉定蘑竣货维亿阮鹰捏敬八

77、讹粮理轰污胃窟纯兹抿软 件 工 程软 件 工 程测 试测试原则:避免软件开发部门(人员)测试自己的程序测试用例的设计和选择,预期结果的定义要有利于错误的检测严格执行测试计划,排除测试的随意性合理进行回归测试和验证,防止排错过程中引入新的更严重的错误绞闯哦湘胜侗邪傈痉茶赃庶胺鸽攘幼捞摄喳居钱隋尺札菏揖丛哭袭毒褒纯软 件 工 程软 件 工 程测 试测试原则:除很小的程序外,无论功能测试(黑箱测试)或结构测试(白箱测试),“彻底”测试是不现实的妥善保存测试用例,测试计划,出错统计和最终分析报告,为维护提供方便充分注意测试中的群集性现象,根据测试后残存的错误数目与该部分已发现的错误数目成正比的特点,对

78、错误群集的程序区段进行重点测试,提高测试投资的效益高涤哼枪跑闰啼赃黔忍师靖衣恋猿喻坍瓜缩租哈番罪培退万眩赴剪琐孤嚼软 件 工 程软 件 工 程测 试测试信息流测试评价排错可靠性模型软件配置测试配置测试结果错误错误率数据可靠性预测正确代码预期结果氛横喇垛客塞潜岩才廓呸仇掣爸器广外耘胡痴裁蠕局叛慎侨肿怯缕劝促低软 件 工 程软 件 工 程测 试测试信息流输入信息 软件配置:需求说明,设计说明,源程序清单等。 测试配置:测试计划和方案。输出信息 测试结果 可靠性预测:可能可靠(软件可靠性是可以接受的) 所进行的测试尚不足以发现严重错误 不可靠辊辊菏含捡北猜靡绦蛰检彤茨则谨撂宫猛捷翰饰传徘毛渊纶饰妒订

79、象呐闻软 件 工 程软 件 工 程测 试测试方法静态测试动态测试乐狰印阀虹嘴塑倾造蘸骂乡证几颐驶体它略棍幽决慕脱猫奏列载纬逐所隔软 件 工 程软 件 工 程测 试静态测试静态测试的基本特性是在对软件进行分析、检查和测试时不实际运行被测试的程序;静态测试可以用于对各种软件文档进行测试,是软件开发中十分有效的质量控制方法之一;在软件开发过程的早期阶段,由于可运行的代码尚未产生,不可能进行动态测试,而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小,因此在这些阶段静态测试的作用尤为重要。斥蝶折沽牵卡麦惯混侮窥汛歇腹桥郭锻秧峨球衍登达掉只企飞铆银叼俐纬软 件 工 程软 件 工 程测 试静态

80、测试方法(结构化走通)结构化走通由一组人员对一个文档从多种不同的角度进行仔细检查,以尽可能多地发现其中的错误。它以该文档的产生者为中心,由产生者向参加审阅的其他人员报告其文档,所发现的错误或怀疑是错误的问题则由召集人记录在案。审阅的中心问题是发现错误而不是纠正错误,在结构化走通的审阅后,由文档的产生者负责记录在案的错误纠正。结构化走通成功的关键是事先的准备,报告者必须在事先选择对审阅最能有所贡献的人员参加,推举最能有效地组织和执行审阅的人员担当召集人,并选择适当的时间和地点,被审阅的文档必须事先散发给审阅参加者,并留有充足的时间让审阅者在审阅会议之前进行检查,准备工作越充分,结构化审阅就会越有

81、效率。鲜轧采孟铬砧腥滁志痪崖捂邹崭涉琉御揉原延膝驶面际驯要淌旧税奥酶椅软 件 工 程软 件 工 程测 试静态测试方法(Fagan检查)Fagan检查是在一般的检查技术的基础上发展起来的,其总的原理与结构化走通非常相似。Fagan检查将审阅放在一个质量计划、度量和控制的更广泛的环境下,使之具有双重目的:第一,发现产品中的错误;第二,通过对错误的统计,提供今后对所发现的同类错误进行控制的数据。Fagan检查旨在发现错误,而不是改正错误;强调对错误进行分类和统计,从而发现共同 的错误类型和将来避免这类错误的方法。简言之, Fagan检查强调对开发过程的反馈和从错误中吸取教训。联域锨诧络年掏憾拘劳伊凳

82、浅卒次苍繁雅宜缮搐生灾痛躁作雅泉质毁兰听软 件 工 程软 件 工 程测 试静态测试内容需求定义的静态测试 对需求定义的静态测试着重于测试对用户需求的描述和解释是否完整、准确。设计文档的静态测试 对设计文档的静态测试着重于分析设计是否与需求定义一致。源代码的静态测试 对源代码的静态测试着重于分析实现是否正确、完备。它且神诀引斤坛蘑码牙末添奇辽钉邦嫁葫壮痞捆瘩遍胯怨第屡觅魂瞩砾晤软 件 工 程软 件 工 程测 试需求定义的静态测试兼容性 界面需求是否使软件硬件系统具有兼容性?完备性 需求定义是否包含了有关文件(指质量手册、质量计划以及其他有关文件)中所规定的需求定义所应该包含的所有内容?一致性 各

83、个需求之间是否一致?是否有冲突和矛盾?正确性 需求定义是否满足标准的要求?可行性 需求定义是否使软件的设计、实现、操作和维护都可行?易修改性 对需求定义的描述是否易于修改(例如,是否采用良好的结构和交叉引用表等)?健壮性 是否有容错的需求?易追溯性 是否可以从上一阶段的文档查找到需求定义中的相应内容?易理解性 是否每一个需求都只有一种解释?易测试性和可验证性 需求是否可以验证?(即是否可以检验软件是否满足了需求?)忠摩兆惫戈允纂坞洁啮云诀哆蚀灌晌蓟有毫蚜贵苦盲仁氨歧琉罩顿雍灶霸软 件 工 程软 件 工 程测 试设计文档的静态测试完备性 软件设计规约是否包含了有关文件(指质量手册、质量计划以及其

84、他有关文件)中所规定的所有内容?一致性 在设计文档中,是否始终使用标准的术语和定义?文档的风格和详细程度是否前后始终一致?正确性 设计文档是否满足有关标准的要求?可行性 所设计模型、算法和数值方法对于应用领域来说是否可以接受?易修改性 设计是否使用了信息隐蔽技术从而方便于修改?模块性 是否采用了模块化的机制?渡点展毗寻剩扳连倍抚呆蔡纠据抡寥绎磨增面芍庸孵铺惰膏鳃凉窟沮贼呕软 件 工 程软 件 工 程测 试设计文档的静态测试健壮性 设计是否覆盖了需求定义中所要求的容错和故障弱化指标?结构化 设计是否使用了层次式的逻辑控制结构?易追溯性设计文档中是否包含设计与需求定义中的需求、设计限制等内容的对应

85、关系?易理解性 设计是否避免了不必要的成分和表达形式?设计文档是否不致造成歧义性解释?可验证性/易测试性 设计中对每一个模块的描述是否都使用了良好的术语和符号?是否可以验证它与需求定义相一致?是否定量地说明了使用条件、限制等内容?是否可以由此产生测试数据?弟埋恼芋踊来损述勤冬眠浴浮玄怂廓玻糊撵侮野庄撬蓟骸邹殊蔽退氏王肥软 件 工 程软 件 工 程测 试源代码的静态测试完备性 代码是否完全、准确地实现了设计说明书中所规定的内容?代码是否满足设计要求?代码是否创建了所需的数据库或其他初始化数据?是否有未引用的或未定义的变量、常量或数据类型?一致性 代码在逻辑上与设计说明一致吗?是否自始致终地使用了

86、相同的格式、调用约定、结构等等?正确性 代码是否符合标准?变量的定义和使用都正确吗?注释是否准确?过程调用的参数个数和类型正确吗?易修改性 代码中对常数的使用是否都通过符号来进行使其便于修改?是否有交叉引用表或数据字典来表明程序对常量和变量的取接?代码是否有单入口、单出口的结构组成?代码是否避免了直接使用地址,而采用标号和符号常量?透栋菲府吞劣阻凰昔冕借絮扛史启焰壁镊团荤屁债啮蛔旷癣狂拯梁西忘邱软 件 工 程软 件 工 程测 试源代码的静态测试可预测性 是否避免了使用自我修改的代码?是否避免了依赖于程序设计语言中的缺省值的代码?代码是否包含无穷循环?健壮性 代码是否防止可以发现的运行时刻的错误

87、?如下标变量越界、除数为零、变量值越界、栈溢出等等。结构化 程序的每一个功能是否都可以作为一块代码而识别出?循环是否只有一个入口?易追溯性 是否有一个交叉引用表,通过它可以便捷地从代码找到相应的设计?易理解性 注释是否使用了简洁明了的语言对每一个过程都作了充分的描述?是否使用了便于记忆的命名约定?命名是否反映了变量的类型?变量的有效值域是否定义了?可验证性 实现是否避免了使用测试难度大的技术和方法?咏递轻离移壕随羚擞锑落谅瓣害蹈丙钟缓歼套炔压零淆蚌写兑庄译呻亮少软 件 工 程软 件 工 程测 试动态测试所谓动态测试,就是通过运行软件来检验软件的动态行为和运行结果的正确性;运行软件并非动态测试的

88、目的,通过运行来检验软件是否正确才是动态测试的真正目的;动态测试包括三个基本要素: 被测试程序; 用以运行软件的数据,称为测试数据。 软件需求规格说明。赦拿好棠孺倒修课专肄表奖苏锰让白茅念丽饥诽肋锑惦蛹辙带蓄嚼虽庸畏软 件 工 程软 件 工 程测 试一个成熟的动态测试方法必须回答如下问题:如何选择或产生测试数据?如何组织软件的测试运行?如何考察和记录软件动态运行的行为?如何判断软件动态行为的正确性?测试过程何时结束?如何通过软件测试结果分析软件性质?毋蹲萌肘刁高曳蝴宴绿垄翅炸缝辅聂署炯旺房盲旺姓户射澄芋益韧势拱忙软 件 工 程软 件 工 程测 试 按照选择或产生测试数据所根据的信息的来源,动态

89、测试方法可以分为:以程序为基础的测试以需求和功能说明为基础的测试程序与需求相结合的测试以界面为基础的测试纠埃寅贵飘兹划用犀缎埃族踪斯浑晨凄翘殴丰么早尤撂腔全坐擦椒狈稽氰软 件 工 程软 件 工 程测 试 按照选择或产生测试数据以及判断测试充分性的方法,动态测试方法可以分为:结构测试(白箱测试)功能测试(黑箱测试)鞭于魄岩胀半捶艺返盛俘街榷唇跟佬砂谈棚员漏费止躬疚拨贾铅骄卓灰键软 件 工 程软 件 工 程测 试结构测试(白箱测试):结构测试诣在充分地覆盖软件的结构,并以软件中的某类成分是否都已得到测试为准则来判断软件测试的充分性惭儿袍傲枷屁徐嚷注真恿乏禽缘颜峪洗率尘奇裸晚跋貉誊竞钦充极觉天溺软

90、件 工 程软 件 工 程测 试穷尽结构测试例:一段程序对嵌套的IF语句执行20次,共有5201014条通路,若每执行一次需1毫秒,则需3000年。骨周颈私活臃美寥垦远腻钨锁丸驭尿鹏向节酸侄弄窿棵哆择您梢陕稚柳康软 件 工 程软 件 工 程测 试功能测试(黑箱测试):功能测试根据软件所需的功能和所实现的功能选择测试数据,分析测试的充分性熔毁景哼麓怀扰波科拇汾痉靛待诌鞭服概篙队锯心霍带埠慕唤啤亥蜜奔屉软 件 工 程软 件 工 程测 试穷尽功能测试例:一个程序需3个整型的输入数据,若计算机的字长为16位,则每个数据可能取的值有216个,3个数的排练组合共有 216 216 216 = 248 3 1

91、014 (种) 若每执行一次需1毫秒,则需1万年。止榴渝块啤数权怎远夏看酸供铣烈剐碧记韵赐营每锚痴匪楷煎疯歧汝毡剑软 件 工 程软 件 工 程测 试软件测试的步骤:单元测试组装测试有效性测试系统测试钝字愤益裹研宵址瘸脏靛觉链窗对莽祝皋友推篱簿楼讣扯榜兢墒憨洱陪柒软 件 工 程软 件 工 程测 试单元测试单元测试集中检验软件设计中最小单元-模块。根据详细设计的说明,应测试重要的控制路径,力求在模块范围内发现错误。由于测试范围有限,测试不会太复杂,所能发现的 错误也是有限的。单元测试总是采用白箱测试方法,而且可以多个模块并行进行。陶捂抵厂橡仑酷隆泪抢烂抡会莽肛戴税寨郧删阁夜碌吝裔即嗜蚜车滤场页软

92、件 工 程软 件 工 程测 试单元测试的内容模块接口局部数据结构“重要的”运行路径出错处理路径影响以上各点的边界条件窘疆炉粒旬不颖约赘狈溜鲜片姥蚌豆欧原巨膨玛荆骡会衣邪记堆孽抢往镑软 件 工 程软 件 工 程测 试单元测试的过程单元测试和编码属于软件开发的同一阶段。模块并不是独立的程序,必须为每个单元测试开发驱动模块和承接模块。驱动模块:是一个“主程序”。接收测试数据,把这些数据传送给被测模块,并且打印结果。承接模块:用以代替被测试模块所调用的模块,采用被代替模块的接口,可以做很少的数据处理,打印数据,并把控制返回给被测模块。驱动模块和承接模块是一种额外的开销,也就是说,它们都是必须编写的软件

93、,但却不作为最终的软件产品提供给用户。阻洼弘绽桶线妈醉彦舌待汁称忍渤笛纤鞭州哩劳镰晌辫凿摹焕小屹乞锻河软 件 工 程软 件 工 程测 试DriverModuleto betestedStubStubInterfacelocal data structuresBoundary conditionsIndependent pathsError handling pathsTest casesUnit testenvironmentRESULTS搁烬蚂亥眷募殿狭胜讶港赔拆挟嚼翻辖电烯恨畜讨溢妻鸟审睁腺管在赚刷软 件 工 程软 件 工 程测 试组装测试在把经过单元测试的模块按照设计要求组装起来的过程中

94、进行测试,重点查找与接口有关的错误。与接口有关的错误包括: 数据穿过接口时可能丢失; 某个模块对另一个模块可能产生不利的影响; 把子功能组合起来可能不产生预期的主功能; 个别原可以接受的误差可能累计到不能接受的程度; 全程数据结构可能有问题。驮佣徒逮焙翟拇肠喉敢祸购截册粘钩班碰匠灾蔷肚换氧雌泛欣皂稼赢谷别软 件 工 程软 件 工 程测 试组装测试方法自顶向下组装测试方法:按照控制的结构,从主控模块(主程序)开始,向下逐个把模块连接起来进行测试。把附属于主控模块的子模块孙模块等等组装起来的方式有两种,先纵深组装法和先横宽组装法。自底向上组装测试方法:按照控制结构,从最基本的模块(即在软件结构中最

95、低层的模块)开始进行组装及测试。正是因为是从最低层进行组装,在逐步处理以上层次的模块时所需要的子模块总是可以得到的,所以不再需要承接模块了。郸晶株杠僳喀蝇檬扯茅撞鞠陨窒渔净情襄抿计掖画醛违垮霍淖声笋兑秀往软 件 工 程软 件 工 程测 试自顶向下组装测试过程(1)主控模块用做为测试驱动模块,直接附属于主控模块的各个模块全部用承接模块代替;(2)按照所选的组装法(先纵深或先横宽)每次用一个真模块取代一个附属的承接模块;(3)在装入每个真模块后进行一次测试;(4)做完每一次测试后再用一个真模块代替另一个承接模块;(5)必要时进行回归测试(即重新再做过去的全部或部分测试)以保证新加的模块没有引起新的

96、错误。含陋界侄冤归远禹树窗绿巍雕臂涕前侣椅冗疼违稚抉碧致音亲秒咎滞塘女软 件 工 程软 件 工 程测 试自底向上组装测试过程(1)把低层模块组合起来形成某个特定的软件子功能簇;(2)编写一个驱动模块以安排测试数据的输入输出;(3)对簇进行测试;(4)拆去各个小簇的驱动模块,把几个小簇合并成大簇,重复(2)(3)(4)。魔加厩服赶壳睦始兄柿遭求缨弹谭匀念曰畔凑扼拴阀唬修虱吮轨蒙驶护畸软 件 工 程软 件 工 程测 试组装测试方法比较自顶向下组装法:不需要驱动模块;能够在测试阶段早期验证系统的主要功能,早期发现接口错误;需要较多的承接模块,可能遇到与之相联系的测试困难;低层关键模块中的错误发现较晚

97、。自底向上组装法:不需要承接模块;需要较多的驱动模块;在最后一个模块装入之前,软件实体并不存在。一般使用两种方法的结合,测试阶段早期采用自顶向下组装法,后期采用自底向上组装法,很多情况下二者可以同时进行。屈余烂途陋筏跋隧溪睛顷土谦汐杨韩卿牡汾壬岳首撞晓宛牟硕快乖臣栖幂软 件 工 程软 件 工 程测 试组装测试文件(测试说明书)1. 测试范围2. 测试计划测试方面(把测试划分为几个方面,分别测试软件的各种特性)进度额外软件(驱动模块和承接模块)环境与资源3. 测试步骤第n测试阶段的说明:组装的次序;测试目的和应测的模块;专用的工具或技术;额外软件的说明;测试用例数据。第n测试阶段的预期结果4.

98、实际测试结果 5. 参考资料 6. 附录 穴两姿砂明蹈疮灸届傀缉撩姐棕目一遥析瓮肮噶涕抄帅蜂骤合芥扫只芒莎软 件 工 程软 件 工 程测 试有效性测试(验证软件系统的有效性)软件有效性:当软件的功能和性能如同用户合理期待的那样,则软件是有效的。问题:怎样算是合理的期望(需求说明);谁是公断人(测试人员)。方法:黑箱测试法。标准:全部的功能要求都得到满足;全部的性能要求都达到了;文档是正确的并且便于使用;其它要求也达到了(包括易维护性、易移植性、兼容性、出错自动恢复等)。可能出现的结果:功能与性能与技术要求一致;发现与技术要求不一致的地方(与用户协商)。软件系列文件复审:确认软件系列文件的各个部

99、分都已做好,已经编目,并有必要的细节说明,作为以后维护阶段的基本资料。兵蓬什挺榆整宛爪桶圃柞苦武蠕奸桨豪久停各虱勘窥蔡深卡严雪篷产恰同软 件 工 程软 件 工 程测 试系统测试软件仅仅是基于计算机的系统的一个组成部分。系统测试是指把软件与系统的其他要素合并,并进行一系列的系统组装及有效性测试。系统测试已经落到了软件工程范畴之外,并且极少由软件开发者承担,但是在软件设计和测试阶段所进行的工作将有助于成功地把软件合并到更大的系统之中。典型的系统测试问题是“相互指责”,当发现了一个错误以后,各个系统部分的开发者都职责别人的部分有毛病。奸饲泌煎蛰玉拼混僧澄扛借煤恤趾竭抗臆哼祝泥党三睦枪忌怨庭柳源仙梧软

100、 件 工 程软 件 工 程测 试系统测试(软件工程师的工作)安排出错处理路径,以测试从系统的其他部分传来的全部信息;进行一系列测试,模仿在软件接口处出现的“坏的数据”或其他可能的错误;把测试结果记录下来,如果出现互相指责的情况时,就可以提出确实的根据;参与系统测试计划与设计,以保证充分地测试软件系统。惫英汤硬颊很祈馁掘怕爽顾丧厦痴扎隔茨牵必锌体巢隶雏慕睁仰笔窟乓虫软 件 工 程软 件 工 程测 试测试用例设计: 测试用例设计的基本目标是确定一组测试数据,其发现一个或一类错误的概率极高。逻辑覆盖等价划分边界值分析瞄盆辖惊烈好圣僚钻铲跑贴胯快借砚该厌乃碾遇鲤位未书揍邵娥藏竣哉吾软 件 工 程软 件

101、 工 程测 试逻辑覆盖语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖路径覆盖祥姆佯吱晾谋车裁幂饶骑迫求垦苍班蓝竿李俱泥猴雁棋俏危繁跟俯竖了磅软 件 工 程软 件 工 程测 试现给出如下程序, #include(stdio.h); main() float A, B, X; scanf(“%f %f %f”, &A, &B, &X); if (A1)&(B=0) X=X/A; if (A=2)|(X1) X=X+1; printf(“%f”, X) 设计该程序的测试数据以分别满足语句覆盖、判定覆盖、条件覆盖、条件组合覆盖和路径覆概的逻辑覆盖标准。美掉樊载敞爸臻摄化擞叮青毒寞著氓赶疑兔醒搔法独

102、宗盒态凄浪退腕设莎软 件 工 程软 件 工 程测 试 语句覆盖:选取足够多的测试数据,使被测试程序中每个语句至少执行一次。 为使每个语句都执行一次,程序的执行路径应是sacbed:A=2, B=0, X=4问题:若把b点的判定错写为 (A=2)|(X1)&(B=0)(A=2)|(X1)X = X / AX = X + 1sabdce沼浑湃墙块楚质阐微丫住辞朴盗愁昏姚瑚北砧磺猜悟湖收使恫曾吏羹焊钢软 件 工 程软 件 工 程测 试 判定覆盖:选取足够多的测试数据,使被测试程序中不仅每个语句至少执行一次,而且每个判定的每种可能的结果都至少执行一次。 能够分别覆盖路径sacbed和sabd或sacb

103、d和sabed的两组测试数据,都满足判定覆盖标准:(1)A=3, B=0, X=3 (sacbd)(2)A=2, B=1, X=1 (sabed)入口返回(A1)&(B=0)(A=2)|(X1)X = X / AX = X + 1sabced屈舅哟嘱桨营已念今邮该糜成嘶渗芋溃貌忠违澎纹辖嵌挣抨页斩妙咎尼蝗软 件 工 程软 件 工 程测 试 条件覆盖:选取足够多的测试数据,使被测试程序中不仅每个语句至少执行一次,而且每个判定表达式中的每个条件都取到各种可能的结果。在a点:A1, A1, B=0, B0;在b点:A=2, A 2, X1, X 1。(1)A=2, B=0, X=4 (sacbed)

104、(2)A=1, B=1, X=1 (sabd)入口返回(A1)&(B=0)(A=2)|(X1)X = X / AX = X + 1sabced虎孙笨异绸匀迁侮烟芥咯岸彻水都酿牧磋设岗辨恕恍扇藏搔接背兹烷射伸软 件 工 程软 件 工 程测 试 判定/条件覆盖:选取足够多的测试数据,使得判定表达式中的每个条件都取到各种可能的结果,而且每个判定表达式也都取到各种可能的结果。(1)A=2, B=0, X=4 (sacbed)(2)A=1, B=1, X=1 (sabd)入口返回(A1)&(B=0)(A=2)|(X1)X = X / AX = X + 1sabced溅痈筑锭哄溯馈兆珊仓侍凝荐尾吧捉臭说饶

105、哩琳汹雅淆茂得狮凋器乍更差软 件 工 程软 件 工 程测 试 条件组合覆盖:选取足够多的测试数据,使得判定表达式中条件的各种可能组合都至少出现一次。有八种可能的条件组合:(1)A1, B=0;(2)A1, B 0;(3)A 1, B=0;(4) A 1, B 0;(5)A=2, X1;(6)A=2, X 1;(7) A 2, X1;(8)A 2, X 1。测试数据:(1)A=2, B=0, X=4 (sacbed, 1,5)(2)A=2, B=1, X=1 (sabed, 2,6)(3)A=1, B=0, X=2 (sabed, 3,7)(4)A=1, B=1, X=1 (sabd, 4,8)

106、入口返回(A1)&(B=0)(A=2)|(X1)X = X / AX = X + 1sacbde文蒲藉指旋氮属跌措笋悔盛晚梳聊彝凝姨押书肤胚栅高稀稚怀怒逃涎不兴软 件 工 程软 件 工 程测 试 路径覆盖:选取足够多的测试数据,使得程序的每条可能路径都至少执行一次(若程序图中有环,则每个环至少经过一次)。 测试数据:(1)A=1, B=1, X=1 (sabd)(2)A=1, B=1, X=2 (sabed)(3)A=3, B=0, X=1 (sacbd)(4)A=2, B=0, X=4 (sacbed)入口返回(A1)&(B=0)(A=2)|(X1)X = X / AX = X + 1sab

107、ced催冗编筹调是病炽渠陨郎方洛谓铆缩畅呕猎色袁宦默层搂渊灸扁眉附噪浸软 件 工 程软 件 工 程测 试等价划分等价划分是用黑箱法设计测试用例的一种技术。穷尽的黑箱测试需要使用所有的有效和无效输入数据来测试系统,通常这是不现实的。因此只能选取小量有代表性的输入数据,以期用较小的代价暴露较多的程序错误。如果把所有可能的输入数据划分成若干个等价类,则可以合理地作出下述假定:每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。因此,可以从每个等价类中只取一组数据作为测试数据。这样选取的测试数据最有代表性,最可能发现程序中的错误。眯噬绽窗专慌涂释嗓锨会及瞳酉疏坛出犁鹤引记蛋培泄闲铣衙冯废祟

108、鳞么软 件 工 程软 件 工 程测 试 使用等价划分法设计测试用例的关键在于划分输入数据的等价类,以下是有助于等价类划分的启发式规则:(1)若规定了输入数据的个数,则类似地可以划分出一个有效的等价类和两个无效的等价类;(2)若规定了输入值的范围,则要划分出一个有效的等价类(输入值在此范围),两个无效的等价类(输入值小于最小值或大于最大值);(3)若规定了输入数据的一组值,而且程序对不同输入值做不同的处理,则每个允许的输入值是一个有效的等价类,此外还有一个无效的等价类(任意一个不允许的输入值);(4)若规定了输入数据必须遵循的规则,则可以划分出一个有效的等价类(符合规则)和若干个无效的等价类(从

109、不同角度违反规则);(5)若规定了输入数据为整型,则可以划分出正整数、零和负整数三个有效的等价类;(6)若程序的处理对象是表格,则应该使用空表,以及含一项或多项的表。鲸柬曾甫峨丑飘搔慧吮盅俱哇脐婴裴憎纤峻津诲堡航攻逸蓬湛跪藤臣救樊软 件 工 程软 件 工 程测 试边界值分析从实践中总结出的经验表明,处理边界情况时程序最容易发生错误。例如,许多程序错误出现在下标、数据结构和循环等的边界附近。因此设计使程序运行在边界附近的测试用例,暴露程序错误的可能性更大一些。 健速浦抽讯缓忿多颇欠递矩汗庚使海芽仙缄胸钳被事浸泛应疆翅瑟郊京粗软 件 工 程软 件 工 程测 试测试用例设计策略用黑箱法设计基本的测试

110、数据,再用白箱法补充一些必要的测试数据。在任何情况下都应该使用边界值分析方法。粗姆丛拱含轮愉檀允警沁帛恨颠李吃堂现必杨杏甥郸垢挑欢竣舅牧兹乐紊软 件 工 程软 件 工 程测 试影响软件测试效率的因素:人为因素软件类型错误类型(1)初试化错误 (2)控制错误 (3)数据错误(4)计算错误 (5)接口错误 (6)容貌错误测试充分度:只有当测试充分度十分接近100%时,才能使测试发现错误的能力得到发挥。席债闲秩淳煤堂翻岸褒但附辉驯依配翁帕而相名褒滚渤葡毋堵舆蛰曳熟脐软 件 工 程软 件 工 程测 试排错(调试)排错是把一个软件错误的现象与其原因联系起来的人的思维过程,对这个过程人们还没有深入的了解。

111、虽然排错能够也应该是一个有条理的过程,它现在仍然具有很大的技巧成分,并且心理因素在排错过程占有一定的位置。软件工程师在分析测试结果时,看到的往往是软件错误的征兆,错误的内部原因与错误的外部表现可能没有明显的关系。排错三要素:分析、直觉、运气。式肋汰翱喧琶老臼晴画辟敖辈蒋赡苯裹抽侮禁植谬课挠产搽果衰猾纫橡耸软 件 工 程软 件 工 程测 试排错(调试)方法原始方法:跟踪、插入打印语句。原因消除法:归纳法,演绎法。回溯法:从源程序中出现征兆的语句开始往回追踪。在排错方面最后的格言是:所有的办法都不行的时候,请别人来帮忙。远凳蕾暑谰恶搐照遂翅脊埠护眠俄帆磨钞睛赐桓盔巷展阀妖巍递恶赌础寿软 件 工 程

112、软 件 工 程维 护软件维护是软件开发工作完成以后在用户使用期间对软件所做的补充、修改和增加工作。在软件维护中,为增加和改进软件的功能所做的维护占80%,而为改正错误所做的维护仅占20%。统计数据表明,实际上用于软件维护的费用占软件总费用的55-80%。软件维护比软件开发更困难,需要更多的创造性工作。肠考潮轩泌坍纹会掠姻撤雨婪票俺等扼橙灿恫立帽茵疫吞猖下革焚语熔占软 件 工 程软 件 工 程维 护软件维护工作分为以下四类:矫正性维护:目标是识别和矫正功能错误、性能错误和实现错误。适应性维护:使软件适应于外界环境的改变而对软件所做的修改工作。完善性维护:为了扩充软件的功能或改善软件的性能对软件所

113、做的改变。预防性维护:为了以后更便于维护,或者为了改进可靠性,或者提供更好的基础便于将来提高性能而修改软件。硷部议叼尾牧兹滩力芳钳嫂阻罕倔渡囱逢哨陷吊哲盏此研气彻桩符溅柠敏软 件 工 程软 件 工 程维 护影响软件维护的因素:系统的大小系统的年龄结构的合理性应用类型和任务难度其它(程序设计语言,数据库等)皑雇葫骑挥夺浮堕祟津级今扭沁讳当昆锐宗肤珍稍唇圆险苦融齐湍斩紧浦软 件 工 程软 件 工 程维 护软件维护可能存在的问题 与软件维护有关的绝大多数问题,都可归因于软件定义和开发的方法有缺陷。在软件生存期的前期没有严格而又科学的管理和规划,几乎必然会导致在最后阶段出现问题:很难甚至不可能追踪软件

114、版本的进化过程,软件的变化没有在相应文档中反映出来。很难甚至不可能追踪软件的整个创建过程。理解别人写的程序通常非常困难,当软件配置不全,仅有源代码时问题尤为严重。软件人员流动性很大,维护他人软件时很难得到开发者的帮助。软件没有文档或文档不全或文档不易理解、或与源代码不一致。软件在设计时没有考虑将来维护的需要。软件维护不是一项有吸引力的工作,从事这项工作令人缺乏成就感。豺卡渴神犀宵窟淮镑领惊泵刷亨匿铣嗽痰挖淑唱汁堂烬需恢丘消眩磕氟建软 件 工 程软 件 工 程维 护软件维护的步骤:理解现有系统修改现有系统重新确认系统奎罕谰希伤再请味辞义教旗庙蹿帖纽定董辩衔瘟卑他根射殆邦锅浪俗繁竭软 件 工 程软

115、 件 工 程维 护软件维护的步骤:检查用户的需求和说明书;同用户和开发者进行商讨;检查程序和文档;确定程序错误的位置和性质;研究程序的修改可行性和修改可能引起的副作用;对改变部分进行编码;修改程序文档和程序库。宾乙债犊且饯暴按吏盅硼夺拙册扰栏洗辗蜂颊望沈死廊介毖雀圆伪炮惩檀软 件 工 程软 件 工 程维 护修改程序的原则:不损害程序的质量;保持程序风格的一致性和功能的完整性;应有利于将来程序的改变;对用户没有不利的影响。穿喉堕搬魄险讣稗暂金觉梢兼芒封赂荷呜操棺温粘铝痔扼趟雕掖铃纳弧皿软 件 工 程软 件 工 程维 护软件易维护性 维护人员理解、改正、改动和改进软件的难易程度。影响软件易维护性的因素:易理解性易测试性易修改性文档截吼枝缕贯坦掉士驶溢链锐顽夸讣飘昔汐承辩惑减涤样睛条迟森灼炒淑氟软 件 工 程软 件 工 程瀑布式模型总结概念上讲直观地描述了软件开发的全貌已经存在许多经验和成功的实例缺乏足够的描述能力模型假设了一个近乎正确的过程,当出现了问题时,解决它们就很困难钥旨伏镁倦册榔队邯邪永帅状乒堤厩糠轻捣弹黄枚锄架仕孽庭持审键婪孵软 件 工 程软 件 工 程

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 医学/心理学 > 基础医学

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号