软件工程11L.docx
- 文档编号:2348615
- 上传时间:2023-05-03
- 格式:DOCX
- 页数:59
- 大小:271.73KB
软件工程11L.docx
《软件工程11L.docx》由会员分享,可在线阅读,更多相关《软件工程11L.docx(59页珍藏版)》请在冰点文库上搜索。
软件工程11L
(十一)软件管理1
基本内容与重点、难点1
教学目标1
具体内容1
11.1 软件质量与质量保证1
11.1.1概述1
11.1.2质量度量模型2
11.1.3软件复杂性2
11.1.4软件可靠性3
11.1.5软件评审4
11.1.6软件容错技术5
11.2 软件工程管理内容6
11.2.1开发人员6
11.2.2组织机构6
⑴主程序员组织机构6
⑵专家组织机构6
⑶民主组织机构6
11.2.3用户6
11.2.4控制7
11.2.5文档资料7
11.3 软件项目计划7
11.3.1软件项目计划概念7
11.3.2软件项目计划内容7
⑴范围7
⑵资源7
11.3.3制定软件工程规范7
11.3.4软件开发成本估算7
⑴成本估算方法7
⑵成本估算模型8
11.4 软件工程标准化与软件文档10
11.5 软件能力成熟度模型CMM12
小结16
习题1117
【补充】软件质量特性的定义17
(十一)软件管理
基本内容与重点、难点
①软件质量的定义和评价,软件质量保证的含义与主要任务;软件质量度量模型(McCall模型,ISO的模型);软件复杂性的概念与度量方法;软件可靠性的定义与评价指标;软件评审(设计质量评审,程序质量评审;软件容错技术(容错软件定义,容错方法,容错软件的设计过程);②软件工程管理(开发人员,组织机构,用户,控制,文档资料管理);软件项目计划的概念与内容,软件工程规范,软件开发成本估算,风险分析,项目进度安排,软件质量保证);软件工程标准化的概念、意义,软件工程标准的层次(国际标准,国家标准,行业标准,企业规范,项目规范),文档的作用与分类;③软件能力成熟度模型CMM。
重点:
①软件质量定义;ISO的软件质量度量模型模型;软件容错方法,容错软件设计过程;②项目计划的内容,开发成本估算,COCOMO估算模型,项目进度安排,软件质量保证;软件工程标准,文档的作用与分类。
教学目标
11.1理解:
软件项目计划的重要性;软件工程标准化;文档的作用与分类
11.2了解:
软件工程管理的内容;项目计划内容;COCOMO模型;Putnam估算模型;CMM模型
具体内容
11.1 软件质量与质量保证
11.1.1概述
1软件质量的定义
软件质量是贯穿软件生存期的一个极为重要的问题,关于软件质量的定义有多种说法,从实际应用来说,软件质量定义为:
⑴与所确定的功能和性能需求的一致性。
⑵与所成文的开发标准的一致性。
⑶与所有专业开发的软件所期望的隐含特性的一致性。
上述软件质量定义反映了以下三方面的问题:
①软件需求是度量软件质量的基础。
不符合需求的软件就不具备质量。
②专门的标准中定义了一些开发准则,用来指导软件人员用工程化的方法来开发软件。
如果不遵守这些开发准则,软件质量就得不到保证。
③往往有些隐含的需求未明确提出,如良好的可维护性。
如果软件只满足那些精确定义的需求而没有满足这些隐含需求,软件质量也不能保证。
软件质量是各种特性的复杂组合。
它随应用的不同而不同,随用户提出的质量要求不同而不同。
2软件质量的度量和评价
一般说,影响软件质量的因素可分为两大类:
⑴可以直接度量的因素,例如:
单位时间内千行代码(KLOC)中所产生的错误数等。
⑵只能间接度量的因素,例如:
可使用性、可维护性等。
在软件开发和维护的过程中,为了定量评价软件质量,必须对软件质量的特性进行度量,从而测定软件所具有要求质量特性的程度。
1976年,Boehm等提出了定量评价软件质量的层次模型;1978年Walters和McCall提出了从软件质量要素、准则到度量的三层次软件质量度量模型;G.Murine根据上述等人的工作结果,提出了软件质量度量(SQM)技术,用来定量评价软件的质量。
图11-1 Boehm软件质量度量模型
3软件质量保证
⑴软件质量保证的含义
软件的质量保证就是向用户及社会提供满意的高质量的产品,确保软件产品从诞生到消亡为止的所有阶段的质量的活动,即确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。
它包括的主要功能有:
质量保证方针和质量保证标准的制定;质量保证体系的建立和管理;明确各阶段的质量保证工作;各阶段的质量评审;确保设计质量;重要质量问题的提出与分析;总结实现阶段的质量保证活动;整理面向用户的文档、说明书等;产品质量鉴定;质量信息的收集、分析和使用。
⑵质量保证的策略
质量保证策略的发展大致分为以下三个阶段:
①以检测为重阶段。
产品生产后才进行检测,这种检测只能判断产品的质量,不能提高产品质量。
②以过程管理为重阶段。
把质量保证工作重点放在过程管理上,对制造过程的每一道工序都进行质量控制。
③以新产品开发为重阶段。
许多产品的质量源于新产品的开发设计阶段,因此在产品开发设计阶段就应采取有力措施来消灭由于设计原因而产生的质量隐患。
由上可知,软件质量保证应从产品计划和设计开始,直到投入使用和售后服务的软件生存期的每一阶段中的每一步骤。
⑶质量保证的主要任务
软件质量保证的任务大致可归结为以下几点:
①正确定义用户要求。
质量保证必须正确定义用户要求,必须十分重视全体开发人员收集和积累的有关用户业务领域的各种业务资料和技术技能。
②技术方法的应用。
开发新软件的方法,最普遍公认的成功方法就是软件工程学的方法。
标准化、设计方法论、工具化等都属此列。
应当在开发新软件的过程中大力使用和推行软件工程学中所介绍的开发方法和工具。
③提高软件开发的工程能力。
只有高水平的软件工程能力才能生产出高质量的软件产品。
因此须在软件开发环境或软件工具箱的支持下,运用先进的开发技术、工具和管理方法提高开发软件的能力。
④软件复用。
利用已有软件成果是提高软件质量和软件生产率的重要途径。
为此,不要只考虑如何开发新软件,而首先应考虑哪些已有软件可以复用,并在开发过程中随时考虑所生产软件的复用性。
⑤发挥每个开发者的能力。
软件生产是人的智能生产活动,依赖于开发组织团队的能力。
开发者必须学习各专业业务知识、生产技术和管理技术。
管理者或产品服务者要制定技术培训计划、技术水平标准,以及适用于将来需要的中长期技术培训计划。
⑥组织外部力量协作。
一个软件自始至终由一软件开发单位开发也许是最理想的。
但现实中常常难以做到。
因此需要改善对外部协作部门的开发管理。
必须明确规定进度管理、质量管理、交接检查、维护体制等各方面的要求,建立跟踪检查体制。
⑦排除无效劳动。
最大的无效劳动是因需求规格说明有误、设计有误而造成的返工。
定量记录返工工作量,收集和分析返工劳动花费的数据非常重要。
另一种较大的无效劳动是重复劳动,即相似的软件在几个地方同时开发。
这多是因软件开发计划不当,或者开发信息不流畅造成的。
为此,要建立互相交流往来通畅、具有横向交流特征的信息流通网。
⑧提高计划和管理质量。
对于大型软件项目,提高工程项目管理能力极其重要。
必须重视项目开发初期计划阶段的项目计划评价,计划执行过程中及计划完成报告的评价。
将评价评审工作在工程实施之前就归纳到整个开发工程的工程计划之中。
⑷质量保证与检验
软件质量必须在设计和实现过程中加以保证。
如果工程能力不够或各种失误导致产生软件差错,结果就会产生软件失效。
为确保每个开发过程的质量,防止把软件差错传递到下一过程,必须进行质量检验。
因此必须在软件开发工程的各个阶段实施检验。
检验实施有两种形式:
实际运行检验(白盒测试和黑盒测试)和鉴定。
可在各开发阶段中结合使用。
11.1.2质量度量模型
下面是几个影响较大的软件质量模型。
1McCall质量度量模型
这是McCall等人于1979年提出的软件质量模型。
针对面向软件产品的运行、修正、转移,软件质量概念包括11个特性。
各个质量特性直接进行度量是很困难的,在有些情况下甚至是不可能的。
因此,McCall定义了一些评价准则,使用它们对反映质量特性的软件属性分级,以此来估计软件质量特性的值。
软件属性一般分级范围从0(最低)到10(最高)。
2ISO的软件质量评价模型
按照ISO/TC97/SC7/WG3/1985-1-30/N382,软件质量度量模型由三层组成,参看图11-2。
高层(toplevel)软件质量需求评价准则(SQRC)
中层(midlevel)软件质量设计评价准则(SQDC)
低层(lowlevel)软件质量度量评价准则(SQMC)
ISO认为,应对高层和中层建立国际标准,在国际范围内推广软件质量管理(SQM)技术而低层可由各使用单位视实际情况制定。
ISO的三层次模型来自McCall等人的模型。
高层、中层和低层分别对应于McCall模型中的特性、度量准则和度量。
其中,SQRC由8个元素组成。
按1991年ISO发布的ISO/IEC9126质量特性国际标准,SQRC已降为6个。
在这个标准中,三层次中的第一层为称为质量特性,第二层称为质量子特性,第三层称为度量。
图11-2ISO的三层次模型
11.1.3软件复杂性
1软件复杂性的基本概念
软件度量的一个重要分支就是软件复杂性度量。
对于软件复杂性,至今尚无一种公认的精确定义。
软件复杂性与质量属性有着密切的关系,从某些方面反映了软件的可维护性、可靠性等质量要素。
软件复杂性度量的参数很多,主要有:
●规则,即总共的指令数,或源程序行数。
●难度,通常由程序中出现的操作数的数目所决定的量来表示。
●结构,通常用与程序结构有关的度量来表示。
●智能度,即算法的难易度。
软件复杂性主要表现在程序的复杂性。
程序的复杂性主要指模块内程序的复杂性。
它直接关系到软件开发费用多少、开发周期长短和软件内部潜藏错误的多少。
同时也是软件可理解性的另一种度量。
减少程序复杂性,可提高软件的简单性和可理解性,并使软件开发费用减少,开发周期缩短,软件内部潜藏错误减少。
为了度量程序复杂性,要求复杂性度量满足以下假设:
●它可以用来计算任何一个程序的复杂性。
●对于不合理的程序,例如对于长度动态增长的程序,或者对于原则上无法排错的程序,不应当使用它进行复杂性计算。
●如果程序中指令条数、附加存储量、计算时间增多,不会减少程序的复杂性。
2软件复杂性的度量方法
⑴代码行度量法
此方法的基本考虑是统计一个程序的源代码行数,并以源代码行数作为程序复杂性的度量。
若设每行代码的出错率为每100行源程序中可能的错误数目,例如每行代码的出错率为1%,则是指每100行源程序中可能有一个错误。
Thayer曾指出,程序出错率的估算范围是0.04%~7%,即每100行源程序中可能存在0.04~7个错误。
他还指出,每行代码的出错率与源程序行数之间不存在简单的线性关系。
Lipow进一步指出,对小程序,每行代码的出错率为1.3%~1.8%;对于大程序,每行代码的出错率增加到2.7%~3.2%之间,但这只是考虑了程序的可执行部分,没有包括程序中的说明部分。
Lipow及其他研究者得出一个结论:
对于少于100行语句的小程序,源代码行数与出错率是线性相关的。
随着程序的增大,出错率以非线性方式增长。
所以,代码行度量法只是一个简单的、估计得很粗糙的方法。
⑵McCabe度量法
McCabe度量法是由ThomasMcCabe提出的一种基于程序控制流的复杂性度量方法。
McCabe复杂性度量又称环路度量,它认为程序的复杂性很大程度上取决于控制的复杂性。
单一的顺序程序结构最简单,循环和选择所构成的环路越多,程序就越复杂。
该方法以图论为工具,先画出程序图,然后用该图的环路数作为程序复杂性的度量值。
程序图是退化的程序流程图,即把程序流程图中每个处理都退化成一个结点,原来连结不同处理符号的流线变成连接不同结点的有向弧,这样得到的有向图叫程序图。
程序图仅描述程序内部的控制流程,完全不表现对数据的具体操作以及分支和循环的具体条件。
因此,它往往把一个简单的IF语句与循环语句的复杂性看成是一样的,把嵌套的IF语句与CASE语句的复杂性看成是一样的。
下面给出计算环路复杂性的方法,如图11-3所示。
根据图论,在一个强连通的有向图G中,环的个数V(G)由以下公式给出:
V(G)=m-n+2p
其中,V(G)是有向图G中环路数,m是图G中弧数,n是图G中结点数,p是G中的强连通分量个数。
在一个程序中,从程序图入口点总能到达图中任一结点,因此,程序图是连通的,但不是强连通的。
为使图成为强连通图,从图的入口点到出口点加一条用虚线表示的有向边,使图成为强连通图。
这样就可使用上式计算环路复杂性了。
以图11-3为例:
结点数n=6,孤数m=9,p=1,则有
V(G)=m-n+2p=9-6+2=5图11-3程序图的复杂性
即McCabe环路复杂度值为5。
这里选择的5个线性无关环路为(abefa),(beb),(abea),(acfa),(adcfa);其他任何环路都是这5个环路的线性组合。
当分支或循环的数目增加时,程序中的环路也随之增加,因此McCabe环路复杂度量值实际上是为软件测试的难易程序提供了一个定量度量方法,同时也间接表示了软件的可靠性。
实验表明,源程序中存在的错误数以及为了诊断和纠正这些错误所需的时间与McCabe环路复杂度度量值有明显的关系。
利用McCabe环路复杂度度量时,有几点说明:
①环路复杂度取决于程序控制结构的复杂度。
当程序的分支数目或循环数目增加时其复杂度也增加。
环路复杂度与程序中覆盖的路径条数有关。
②环路复杂度是可加的。
例如,模块A复杂度为3,模块B复杂度为4,则模块A与B的复杂度是7。
③McCabe建议,对于复杂度超过10的程序,应分成几个小程序,以减少程序中的错误。
④这种度量的缺点是:
●对于不同种类的控制流的复杂性不能区分;
●简单IF语句与循环语句的复杂同等看待;
●嵌套IF语句与简单CASE语句复杂性一样;
●1000行的顺序程序与1行语句复杂性相同。
尽管McCabe环路复杂度度量法有许多缺点,但它容易使用,而且在选择方案和估计排错费用等方面都是很有效的。
11.1.4软件可靠性
软件可靠性是最重要的软件特性。
通常它衡量在规定的条件与时间内,软件完成规定功能的能力。
1软件可靠性定义
软件可靠性表明一个程序按照用户的要求和设计的目标,执行基本功能的正确程度。
一个可靠的程序要求是正确,完整,一致和健壮的。
但现实中一个程序要达到完全可靠是不实际的,要精确度量它也不现实。
一般情形下只能通过程序测试去度量程序的可靠性。
软件可靠性是指在给定的时间内,在规定的环境条件下系统完成所指定的功能的概率。
2软件可靠性指标
软件可靠性与可用性的定量指标是指能够以数字概念来描述可靠性的数学表达式中所使用的量。
常借用硬件可靠性的定量度量方法来度量软件可靠性与可用性。
下面讨论常用指标MTTF与MTBF。
⑴MTTF(MeanTimeToFailure)
设对n个相同的系统(硬件或软件)进行测试,其失效时间分别是t1,t2,…tn,则平均失效等待时间MTTF定义为:
对于软件系统,这相当于同一系统在n个不同环境(即使用不同测试用例)下进行测试。
因此,MTTF是一个描述失效模型或一组失效特性的指标量。
该指标的目标值应由用户给出,在需求分析阶段纳入可靠性需求,作为软件规格说明提交开发部门。
在运行阶段,可把失效率函数λ(t)视为常数λ,则平均失效等待时间MTTF是失效率λ的倒数:
MTTF=1/λ。
⑵MTBF(MeanTimeBetweenFailures)
平均失效间隔时间MTBF是指两次相继失效之间的平均时间。
MTBF在实际使用时通常是指当n很大时,系统第n次失效与第n+1次失效之间的平均时间。
对于失效率λ(t)为常数和修复时间(MTTR)很短的情况,MTTF与MTBF几乎相等。
3软件可靠性模型
计算机硬件可靠性度量之一是它的稳定可用程度,用其错误出现和纠正的速率来表示。
令MTTF是机器的平均无故障时间。
MTTR是错误的平均修复时间,则机器的稳定可用性可定义为:
A=MTTF/(MTTF+MTTR)
对软件可靠性数学理论的研究程度已经导致产生了一些有希望的可靠性模型,通常分为如下几类:
⑴由硬件可靠性理论导出的模型。
硬件可靠性工作的模型有如下假设:
●错误出现之间的调试时间与错误出现率呈指数分布,而错误出现率和剩余错误呈正比;
●每个错误一经发现,立即排除;
●错误之间的故障率为常数。
对软件来说,每个假设的合法性可能还是个问题。
例如,纠正一个错误的同时可能不当心而引入另一些错误,这样第二个假设显然并不总是成立。
⑵基于程序内部特性的模型。
基于程序内部特性可靠性模型计算存在于软件中的错误的预计数。
根据软件复杂性度量函数给出定量关系,这类模型建立了程序的面向代码的属性(如操作符和操作数的数目)与程序中错误的初始估计数字之间的关系。
⑶植入模型。
植入可靠性模型是在软件中植入已知错误,并计算发现的植入错误数与发现的实际错误数之比。
随机将一些已知的带标记的错误植入程序,在历经一段时间的测试之后,假定植入错误和程序中的残留错误都可以同等难易地被测试到,就可求出程序中尚未发现的残留错误总数。
这种模型依赖于测试技术。
但如何判定哪些错误是程序的残留错误,哪些是植入带记号的错误,不是件容易的事。
而且植入带标记的错误有可能导致新的错误。
还有其他软件可靠性模型,例如外延式。
关于软件可靠性模型的研究工作尚在初始阶段。
11.1.5软件评审
人的认识不可能100%符合客观实际,因此在软件生存期每个阶段的工作中都可能引入人为错误。
在某一阶段中出现的错误,如果得不到及时纠正,就会传播到开发的后续阶段中去,并在后续阶段都要采用评审的方法,揭露软件中的缺陷,然后改正。
通常,把“质量”理解为“用户满意程度”。
为使得用户满意,有两个必要条件:
一.设计的规格说明书要符合用户的要求。
二.程序要按照设计规格说明所规定的情况正确执行。
上述条件一称设计质量,条件二称程序质量。
过去多把程序质量当做设计质量,但优秀的程序质量是构成好的软件质量的必要条件,而非充分条件。
软件的规格说明分为外部规格说明和内部规格说明。
外部规格说明是从用户角度来看的规格,包括硬件/软件系统设计(在分析阶段进行)、功能设计(在需求分析阶段与概要设计阶段进行)。
内部规格说明是为了实现外部规格的更详细的规格,即软件模块结构与模块处理过程的设计(在概要设计与详细设计阶段进行)。
因此,内部规格说明是从开发者角度来看的规格说明。
将上述两个概念联系起来,设计质量是由外部规格说明决定的,程序质量是由内部规格说明决定的。
1设计质量的评审内容
设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明,在软件概要设计阶段产生的软件概要设计说明书等。
通常需要从以下几个方面进行评审。
①评价软件的规格说明是否合乎用户的要求,即总体设计思想和设计方针是否明确;需求规格说明是否得到了用户或单位上级机关的批准;需求规格说明与软件的概要设计规格说明是否一致等。
②评审可靠性,即是否能避免输入异常(错误或超载等)、硬件失效及软件失效所产生的失效,一旦发生应能及时采取代替手段或恢复手段。
③评审保密措施实现情况,即是否提供对使用系统资格进行检查;对特定数据的使用资格、特殊功能的使用资格进行检查,在查出有违反使用资格情况后,能否向系统管理人员报告有关信息;是否提供对系统内重要数据加密的功能等。
④评审操作特性实施情况,即操作命令和操作信息的恰当性,输入数据与输入控制语句的恰当性;输出数据的恰当性;应答时间的恰当性等。
⑤评审性能实现情况,即是否达到所规定性能的目标值。
⑥评审软件是否具有可修改性、可扩充性、可互换性和可移植性。
⑦评审软件是否具有可测试性。
⑧评审软件是否具有复用性。
2程序质量的评审内容
程序质量评审从开发者的角度进行评审,直接与开发技术有关,是着眼于软件本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。
⑴软件的结构
为使得软件能满足设计规格说明要求,软件结构本身必须优秀。
包括:
①功能结构。
在软件的各种结构中,功能结构是用户惟一能见到的结构。
因此,功能结构可以说是联系用户跟开发者的规格说明,它在软件的设计中占有极其重要的地位。
在讨论软件的功能结构时,必须明确软件的数据结构。
需要检查的项目有:
●数据结构:
包括数据名和定义;构成该数据的数据项;数据与数据间的关系。
●功能结构:
包括功能名和定义;构成该功能的子功能;功能与子功能之间的关系。
●数据结构和功能结构之间的对应关系:
包括数据元素与功能元素之间的对应关系;数据结构与功能结构的一致性。
②功能的通用性。
在软件的功能结构中,某些功能有时可以作为通用功能反复出现多次。
从功能便于理解、增强软件的通用性及降低开发的工作量等观点出发,希望尽可能多地使功能通用化。
检查功能通用性项目包括:
●抽象数据(包括抽象数据的名称和定义,抽象数据构成元素的定义);
●抽象功能结构。
③模块的层次。
模块的层次是指程序模块结构。
由于模块是功能的具体体现,所以模块层次应当根据功能层次来设计。
④模块结构。
上述模块层次结构是模块的静态结构。
现要检查模块间的动态结构。
模块分处理模块和数据模块两类,模块间的动态结构也与这些模块分类有关。
对这样的模块结构进行检查的项目有:
●控制流结构:
规定处理模块之间的流程关系。
检查处理模块之间的流程关系;检查处理模块之间的控制转移关系与控制转移形式(调用方式)。
●数据流结构:
规定了数据模块是如何被处理及模块进行加工的流程关系。
检查处理模块与数据模块之间的对应关系;处理模块与数据模块之间的存取关系,如建立、删除、查询、修改等。
●模块结构与功能结构之间的对应关系:
包括功能结构与控制流结构的对应关系;功能结构与数据流结构的对应关系;每个模块的定义(包括功能、输入与输出数据)。
⑤处理过程的结构。
处理过程是最基本的加工逻辑过程。
对它的检查项目有:
●要求模块的功能结构与实现这些功能的处理过程的结构应明确对应;
●要求控制流应是结构化的;
●数据的结构与控制流之间的对应关系应明确,并可依这种对应关系来明确数据流程的关系;
●用于描述的术语标准化。
⑵与运行环境的接口
运行环境包括硬件、其他软件和用户。
与运行环境的接口应设计得较理想,要预见到环境的改变,并且当一旦要变更时,应尽量限定其变更范围和变更所影响的范围。
主要检查项目有:
①与硬件的接口。
包括与硬件的接口约定,即根据硬件的使用说明等所做出的规定;硬件故障时的处理和超载时的处理。
②与用户的接口。
包括与用户的接口规定;输入数据的结构;输出数据的结构;异常输入时的处理;超载输入时的处理;用户存取资格的检查等。
③随着软件运行环境的变更,软件的规格也在跟着不断地变更。
运行环境变更时的影响范围,需要从以下三个方面来分析:
其一是与运行环境的接口。
其二是在每项设计工程规格内的影响。
其三是在设计工程相互间的影响。
上述其一是变更的重要原因。
其二是在每个软件结构范围内的影响。
例如,若改变某一功能,则与之相联系的父功能和其子功能都会受到影响。
如果变更某一模块,则调用该模块的其他模块都会受到影响。
其三是指不同种类的软件结构相互间的影响。
例如改变某一功能时,会影响到模块的层次及模块结构,这些多模块的处理过程都将产生影响。
11.1.6软件容错技术
提高软件质量的技术可分为两类:
①避开错误(fault-avoidance,开发过程中不让差错潜入软件)技术;②另一类是容错(fault-tolerance,对某些无法避开的差错,使其影响减至最小)技术。
避开错误技术是进行质量管理,实现产品应有质量所必不可少的技术。
但无
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 11