软件工程代码总结

软件工程代码总结（精选8篇）

软件工程代码总结篇1

处理事件的方法

2、class和id的用途是不一样的；首先要说明一下，选择器一共有三种：

html标记，class,id;html标记就不说了，class是对html标记选择器的一种扩展，CLASS可以给多个标记反复利用；而ID的目的在于被Javascript使用，来动态改变CSS，所以2种的实际用途是截然不同的。

如：“id”对应“#”,“class”对应“.”.id是唯一标志的，在同一页面中不能有相同的值,class则没这约束。如： Css #div1{......}.div2{......}

软件工程代码总结篇2

1977年,McCall等提出从产品运行、产品修订、产品变迁三方面考量软件质量模型[1]。1978年,Boehm等提出了定量评价软件质量的概念,给出了60个度量公式,并首次提出分层结构的软件质量模型[2,3]。ISO于1991年发布ISO9126标准,提出了高层软件需求质量评价准则、中层软件设计质量评价准则、低层软件代码质量度量评价准则的3层质量模型[4]。我国在GB/T 16260.1和GJB 5236定义了软件的内外部质量模型,将软件质量划分为功能性、可靠性、易用性、效率、可维护性和可移植性六个特性,每个特性又进一步细分为若干子特性。外部度量是通过测试、运行和观察可执行的软件,由该软件所占系统行为的测度而导出;内部度量指通过对中间产品静态属性的测量来预测软件外部质量特性[5]。根据产品的业务目标和评价者的要求,选择质量度量的基础也不同,用户一般根据使用软件的结果,发行方一般根据功能性、可靠性、易用性、效率等外部度量准则,开发人员一般根据内部度量准则。文献[6]对现有软件质量模型进行了系统的总结。

代码是软件的中间产品,代码静态质量度量的是软件内部属性,通过它可以预测软件的外部质量测度。需要指出的是,软件开发过程中产品质量的定量评价还比较困难[7],主要是因为软件内部属性在外部质量测度上的作用是由经验决定的,并且依赖于软件的使用环境,度量模型及参数并不惟一,要根据行业特点进行选择,而国内这方面的工作很少,文献[8]提出了一种度量元标准值的计算方法。

1 雷达软件静态质量评价现状

雷达软件按技术特点划分成若干配置项:雷控软件、发射控保软件、接收软件、信号处理软件、数据处理软件、综合显示软件,还可能包括伺服控制软件、波束控制软件、反干扰软件、微波通信软件等。其具有运行平台多样、对实时性稳定性要求高的特点,通常采用C和C++语言进行开发,代码中既有面向过程的又有面向对象的。现在雷达软件代码静态质量分析一般是先使用静态分析工具进行分析,然后查看关心的度量元,没有对代码的静态质量进行系统地分析。而且商用代码静态分析工具只是通过函数、类和系统各自的度量元来计算其质量准则,并没有考虑成员函数对类、类对系统质量准则的影响。雷达软件代码静态质量的关注点通常集中在函数层面,对系统和类较少关注,而这两个层面的静态质量也是需要关注的。

本文以现有代码静态质量模型为基础,根据实际测评过程中关注的要点对其进行调整,并考虑了质量准则值在不同度量范围之间的传递关系,提出了一种计算软件代码静态质量的方法,它可以方便地计算出被评软件代码的静态质量,具有定义清晰、层次关系合理、度量元获取方便的特点。

2 雷达软件代码静态质量模型

新方法采用的是符合GB/T16260规定的软件质量三层模型,分为质量特性、准则和度量元三个层次,按照GB/T16260的描述,软件静态质量主要反映软件的可维护性,准则层包括可分析性、可修改性、稳定性和可测试性四个准则,根据工作需要,度量元选取以商用代码质量分析工具提供的度量元为基础,辅以人工统计的度量元,度量范围分为系统域、类域和函数域。

质量特性中的可维护性是指软件对已完成的部分进行调整需要多大的努力。质量准则中的可分析性是指软件便于发现失效或定位要修改位置的能力;可修改性是指软件便于修改或完善的能力;稳定性是指软件修改不会导致意外结果引发风险的能力;可测试性是指软件便于验证的能力。

2.1 新方法的计算原理

系统域、类域、函数域的复合准则值由自身所含度量元计算的准则值和子域传递准则值构成,权重分别为w1、w2,设每个成员函数的准则值对所属类准则值的影响权重相同,每个类准则值对所属系统准则值的影响权重相同。计算公式如下

式(1)中:ΩA,ΩC,ΩM分别表示系统域、类域、函数域度量元的合理范围,若度量元在规定范围内,则对应的度量元值为1,若在范围外,则对应的度量元值为0。ASMk为系统的第k个度量元取值,CSMik表示类i的第k个度量元取值,MSMijk表示类i的成员函数ij的第k个度量元取值。A表示系统域度量元个数,C表示类域度量元个数,M表示类域度量元个数。

式(2)中:ASC表示归一化的系统域准则值,CSCi表示归一化的类i的类域准则值,MSCij表示归一化的类i成员函数ij的函数域准则值。

式(3)中:CSCCi表示归一化的类i的类域复合准则值,bi表示类i中成员函数的个数。

式(4)中:ASCC表示归一化的系统域复合准则值,n表示系统中类的个数。

2.2 系统域度量模型

系统域选取了A1～A14共14个度量元,见表1,主要从类和成员函数的总体特点进行度量[9,10]。每个质量准则值选5个对其影响最大的度量元计算得到,见图1。系统域复合准则值等于自身准则值和类域传递准则值的加权和。

2.3 类域度量模型

类域选取了C1～C12共12个度量元,见表2,从类自身编码的特点和类与类之间的关系进行度量。每个质量准则值选5个对其影响最大的度量元计算得到,具体见图2。类域复合准则值等于类自身准则值和函数域传递准则值的加权和。

2.4 函数域度量模型

函数域选择了M1～M16共16个度量元,见表3,从函数自身编码的特点和函数之间的相互调用进行度量。每个质量准则值选5个对其影响最大的度量元计算得到,见图3。

3 试验验证

以某型雷达数据处理软件的代码作为评价对象,从中选取了12个类共89个函数,进行度量试验。以类1为例,类1共有5个成员函数,表4中包含了每个函数的函数域度量元统计值和根据图3所示的函数质量模型得到的每个函数的函数域准则值。

类1的类域度量元统计值如表5所示:

根据式(2)和图2计算得到类1的自身准则值,根据式(3)计算得到类1的复合准则值,在复合准则值的构成中自身度量元计算得到的准则值所占的比重w1=50%,子域传递准则值所占的比重w2=50%。结果如表6所示:

表7中记录了被评软件中所含的12个类的类域复合准则值。

从表7中可以看到,被评软件中12个类的复合质量准则值都超过了0.6分,达到了及格水平。总体上看,类的可修改性和稳定性较好,可分析性和可测试性相对较差,原因是被测软件成员函数与圈复杂度相关的度量元普遍超标。

下面是实验结果的玫瑰图,图4(a)、图5(a)和图6(a)是系统域、类域和函数域自身度量元的玫瑰图。图中正多边形的边界表示度量元合理范围的上下边界,不规则多边形是实测的度量元,*形点表示度量元在规定范围内,o形点表示度量元在规定范围外,A1～A14对应表1中系统域的14个度量元,C1～C12对应表2中类域的12个度量元,M1～M16对应表3中函数域的16个度量元。图4(b)、图5(b)和图6(b)分别是系统域、类域和函数域的准则值玫瑰图,图中正菱形表示准则值满分时的边界,浅色实线表示自身度量元计算得到的准则值,深色实线表示复合准则值,标注值为复合准则值。

由图4(a)中可以看到,被评软件在14个系统域度量元中有3个超标,分别为:A7重载函数所占比例、A10未被使用函数所占的比例、A13基本圈复杂度超标比例,说明系统中重载函数的比例较低,未使用函数的比例较高,基本圈复杂超标比例较高。根据图1所示的系统域质量准则模型,系统的可修改性、稳定性和可测试性受到小幅影响,在图4(b)中可以看到影响的程度,图4(b)中还可以看到复合后的系统域准则值与系统域自身度量元计算得到的准则值基本吻合。

由图5(a)中可以看到,被评类在12个类域度量元中有4个超标,分别为:C5成员函数基本圈复杂度均值、C6成员函数基本圈复杂度超标比例、C7成员函数圈复杂度与基本圈复杂度乘积的均值、C8成员函数圈复杂度与基本圈复杂度乘积的超标比例。根据图2所示的类域质量准则模型,被测类的可分析性、可修改、稳定性、可测试性均受到影响,其中可分析性和可测试性受影响较大,在图5(b)中可以看到受影响的程度,图5(b)中还可以看到复合后的准则值与类域自身度量元计算得到的准则值基本吻合。

由图6(a)中可以看到,被评函数在16个函数域度量元中有6个超标,分别为:M9出口语句条数、M11圈复杂度、M12基本圈复杂度、M13圈复杂度与基本圈复杂度的乘积、M14控制结构最大嵌套层数、M15可执行路径数。根据图3所示的函数域质量准则模型,函数的可分析性、可修改性、稳定性、可测试性都受到较大影响,其中可测试性受影响的程度最大,在图6(b)中可以看到这一结果。

4 结束语

目前雷达软件代码静态质量度量中存在度量手段单一,度量方法不能满足实际需要的问题。针对这些问题,本文提出了新的代码静态质量度量方法,采用通用的软件质量三层模型,划分了系统域、类域、函数域三个度量范围,考虑了质量准则从子域向父域的传递,并使用玫瑰图将代码静态质量直观地表达出来,试验结果表明该方法能够有效地对软件代码静态质量进行度量,帮助开发人员和管理人员了解代码的结构状态,有针对性的提高软件编码质量。需要指出的是,如何选取代码的静态度量元表示质量准则还没有定论,本文所提的质量模型主要参考了商业软件以及平时的工作经验,如何通过较为严谨的证明说明所选度量元的合理性可作为后期的研究内容。

摘要：通过软件静态质量分析可以定量评价软件代码的质量。文章通过对软件代码静态质量度量模型的研究,考虑质量准则在不同度量范围间的传递,结合雷达软件代码质量的关注点,提出雷达软件静态质量度量方法,以量化数据表示代码的质量水平,并以玫瑰图的形式表示出来。试验结果表明,新的度量方法能够有效地对软件静态质量进行度量,为设计师了解软件代码质量水平提供了客观依据,减少了软件质量评估中的主观性。

关键词：软件静态质量,度量方法,玫瑰图

参考文献

[1]Mccall J,Richards P,Walters G.Factors in software quali-ty[R].Technical report CDRL A003,US Rome air devel-opment centre,1977.

[2]Boehm B W,Brown J R,Kaspar H.Characteristics of soft-ware quality(TRW serious of software technology)[M].New York:Elsevier science Ltd,1978.

[3]Boehm B W,Brown J R.Quantitative evaluation of soft-ware quality[C]//ICSE′76Proceedings of the 2nd interna-tional conference on software engineering.University ofCalifornia:IEEE Computer society,1976:592-605.

[4]ISO/IEC 9126 1 2001.Software engineering Productquality Part 1:Quality model[S].

[5]GB/T 16260 1 2006.软件工程产品质量第1部分质量模型[S].

[6]吴坚,吴刚.软件质量模型的研究[J].计算机工程与科学,2006,28(6):125-130.

[7]何新贵.软件测试技术综述[J].中国计量学院学报,2008,19(3):187-193.

[8]孙梦璘,宋晓秋,巢翌.软件程序代码质量度量技术研究[J].计算机工程与设计,2006,27(2):325-327.

[9]Telelogic A B.Telelogic Tau Logiscope Audit C++Ref-erence Manual(Revision 6.5)[R].London,2008.

浅谈软件静态测试中的代码审查篇3

关键词：软件代码审查；代码审查过程；代码审查问题

中图分类号：TP311.52文献标识码：A文章编号：1007-9599 (2012) 03-0000-02

Discussion on the Code Review of Software Static Testing

Yuan Zhengjiang

(Jiangnan Institute of Electrical and Mechanical Design,Guiyang550009,China)

Abstract:This paper describes the software code to examine the role,content,code review process,and lists some common problems of code review.

Keywords:Software code review;Code review process;Code review problem

一、引言

软件测试常用方法可分为动态测试和静态测试，只有动态测试和静态测试有效结合，才能更好的完成软件测试工作。代码审查是软件静态测试中常用的软件测试方法之一，代码审查时，只要测试人员方法得当、足够细心，往往能够产生意想不到的效果。

二、代码审查的作用

代码审查是在不执行软件的条件下有条理的仔细审查软件代码，从而找出软件缺陷的过程。

代码审查可以找出动态测试难以发现或隔离的软件缺陷。在开发过程初期让测试人员集中精力进行软件代码审查非常有价值：可以提高代码质量；在项目的早期发现缺陷，将损失降至最低；促进团队沟通、促进知识共享、共同提高。

代码审查还可以为动态测试时设计和执行测试用例提供思路。通过代码审查，可以确定有问题或者容易产生软件缺陷的特性范围。

三、代码审查的过程

代码审查过程可分为：代码审查策划阶段、代码审查实施阶段以及代码审查总结阶段。

（一）代码审查策划阶段

1.项目负责人分配代码审查任务；

2.确定代码审查策略：依据软件开发文档，确定软件关键模块，作为代码审查重点；将复杂度高的模块也作为代码审查的重点；

3.项目负责人确定代码审查单，审查内容一般可包括：

（1）可追溯性：

——代码是否遵循详细设计？

——代码是否与需求一致？

（2）逻辑：

——表示优先级的括号用法是否正确？

——代码是否依赖赋值顺序？

——“if…else”和“switch”使用是否正确清晰？

——循环能否结束？

——复合语句是否正确地被花括号括起来？

——case语句是否所有可能出现的情况均已考虑？

——“goto”是否使用？

（3）数据：

——变量在使用前是否已初始化？

——变量的声明是否按组划分为外部的和内部的？

——除最明显的声明外，是否所有声明都有注释？

——每个命名是否仅用于一个用途？

——常量名是否都大写？

——常量是否都是通过“#define”定义的？

——用于多个文件中的常量是否在一个头文件中定义？

——头文件中是否存在可执行的代码？

——定义为指针的变量是否作为指针使用（而不是作为整数）？

——指针是否初始化？

——释放内存后是否将指针立即设置为NULL（或0）？

——传递指针到另一个函数的代码是否首先检查了指针的有效性？

——通过指针写入动态分配内存的代码是否首先检查了指针的有效性？

——宏的命名是否都大写？

——数组是否越界？

（4）接口：

——在所有的函数及过程调用中，参数的个数都正确吗？

——形参与实参类型匹配吗？

——参数顺序正确吗？

——如果访问共享内存，是否具有相同的共享内存结构模式？

（5）文档：

——软件文档是否与代码一致？

（6）注释：

——注释与代码是否一致？

——用于理解代码的注释是否提供了必要的信息？

——是否对数组和变量的作用进行了描述？

（7）异常处理：

——是否所有可能的错误都已加以考虑？

（8）内存：

——在向动态分配的内存写入之前是否检查了内存申请是否成功？

——若采用动态分配内存，内存空间分配是否正确？

——当内存空间不再需要时，是否被明确的释放？

（9）其它：

——是否检查了函数调用返回值？

——所有的输入变量都用到了吗？

——所有的输出变量在输出前都已赋值了吗？

4.确定代码审查进度安排，项目负责人负责安排代码审查的进度。

（二）代码审查实施阶段

1.代码讲解：软件开发人员详细向测试人员讲解如何以及为何这样实现，测试人员提出问题和建议。通过代码讲解，测试人员对被审查的软件有了一个全面的认识，为后续代码审查打下良好的基础。

2.静态分析：一般采用静态分析工具进行，主要分析软件的代码规模、模块数、模块调用关系、扇入、扇出、圈复杂度、注释率等软件质量度量元。静态分析在代码审查时应优先进行，有利于软件测试人员在后续代码审查时对软件建立宏观上认识，在审查中容易做到有的放矢，更易于发现软件代码中的缺陷。

3.规则检查：采用静态分析工具对源程序进行编码规则检查，对于工具报出的问题再由人工进行进一步的分析以确认软件问题，是一种比较有效的方法。

4.正式代码审查：代码审查可分两步进行：独立审查和会议审查。根据情况，这两步可以反复进行多次。

（1）独立审查：测试人员根据项目负责人的工作分配，独自对自己负责的软件模块进行代码审查。测试人员根据代码审查单，对相关代码进行阅读、理解和分析后，记录发现的错误和疑问。

（2）会议审查：项目负责人主持召开会议，测试人员和开发人员参加；测试人员就独立审查发现的问题和疑问与开发人员沟通，并讨论形成一致意见；对发现的问题汇总，填写软件问题报告单，提交开发人员处理。

5.更改确认：开发人员对问题进行处理，代码审查人员对软件的处理情况进行确认，验证更改的正确性，并防止出现新的问题。

（三）代码审查总结阶段

代码审查工作结束后，项目负责人总结代码审查结果；编写测试报告，对软件代码质量进行评估，给出合理建议。

把代码审查提出的所有问题、亮点及最终结论详细的记录下来，供其他软件项目代码审查借鉴。必要时，可建立常见软件代码缺陷数据库，为软件代码审查人员培训和执行代码审查提供数据支持，也可以为软件编码规则制定规范提供实践依据。

四、代码审查中的常见问题

如果软件测试人员熟悉常见的软件代码审查问题，对代码审查效率是很有帮助的。笔者根据自己的应验，列举部分常见软件代码审查问题如下（仅供参考）：

（1）浮点数相等比较：可能造成程序未按设计的路径执行；

（2）因设计原因导致某些代码不能执行：如逻辑表达式永远为真（或假）造成某分支不能执行、代码前面有return语句、某模块从未被调用等；

（3）switch语句没有break语句（有意如此设计时除外）；

（4）数组越界使用：数组越界容易发生在数组下标是计算得到的情况下，而且审查时很难发现这种代码缺陷，应加以重视；

（5）变量未初始化就使用或者是条件赋值就使用；

（6）程序中存在未使用的多余变量；

（7）复合逻辑表达式没有使用括号造成运算顺序错误；

（8）有返回值的函数中return没有带返回值；

（9）逻辑判别的表达式不是逻辑表达式；

（10）动态分配的内存没有及时释放：忘记写内存释放代码或由于其它逻辑缺陷导致内存释放代码未得到执行；

（11）没有对缓冲区溢出进行必要的防护；

（12）访问空指针，即指针未初始化就使用；

（13）指针指向的内存释放后，未将指针置为NULL：其它函数访问该指针时，判断指针不为空，当作有效指针使用，会造成内存访问错误；

（14）注释说明与程序代码实现不一致，甚至相反；

（15）循环存在不能跳出的可能，程序中没有相应的保护机制。

五、结束语

软件代码审查是重要的软件测试方法之一，软件测试单位应建立完善的代码审查规程，规范代码审查过程。代码审查人员应善于使用软件静态分析工具，善于总结代码审查经验。软件代码审查工作做得扎实，可以发现很多软件编码隐含的缺陷，提高软件的可靠性，为后续的动态测试打下良好的基础。

[作者简介]袁政江（1977.5-），男，江南机电设计研究所，本科，工程师，研究方向：软件开发与测试。

机构信用代码专项宣传活动总结篇4

按照人民银行XXX支行的安排部署，我单位从XXXX年XX月XX日起，开展了机构信用代码专项宣传活动，通过宣传机构信用代码制度建设的背景、作用和重要意义等内容，使广大客户明白了办理信用代码后，能够通过信用代码更加便捷、迅速地实现银行内部、银行与银行之间、银行与监管部门之间的信息共享，为客户自身享受全国范围内统一、优质的金融服务提供了便利。因此，客户开立结算账户许可证时都主动要求办理机构信用代码，宣传收到了很好效果。现将具体情况总结汇报如下：

一是加强领导，精心组织。按照XX人行征信办公室有关机构信用代码专项宣传活动的安排部署，我单位召开了专门会议进行研究，决定由主管业务的副主任主抓，业务经营部、综合事务部、计财科技部具体负责，依据人民银行制订的活动方案，并结合自身实际迅速展开相关宣传工作。

二是利用客户办理业务的时候和他们一对一面谈方式进行宣传。在全市选择企业客户最多的四大城区网点作为机构信用代码专项宣传的重点，要求每个会计人员和信贷客户经理在客户开立结算账户和办理信贷业务时，都必须向他们面对面、一对一座谈的方式进行宣传。那样容易讲深讲透，客户也更好理解并接受有关宣传的信息。

三是通过悬挂电子显示屏滚动显示宣传口号进行宣传。全市各辖内营业网点安装的XX块电子显示屏都全部打上了宣传口号，进行滚动式的宣传。四是在乡村集镇营业网点悬挂纸质标语横幅进行宣传。全辖共悬挂纸质横幅XX条，标语XX余张。

软件工程代码总结篇5

屏幕全黑无显示进入维修模式。

再按#键再按插入键再按C键再按插入键，20按按开始按1按开始[会出现0000000]完成。按CA 退CA 退出，这个是清除保养维护周期的.消小人灯（计数保养）。再按42按按开始按按开始[会出现0000000]完成。按

出，这个是清除载体寿命周期的.消太阳灯（载体计数清除）

如果你觉得效果没问题的，消去是没影响的。

更换载体和鼓芯

准备工作：口罩一个，油漆毛刷一个，报纸若干，橡胶手套一副。最好是晚上关灯操作。

1、先要拉出机器侧面的盖板,打开机器的腹部盖板，你就会看到粉仓的按钮（绿色部分），按住按钮，往外拉出粉仓。拿出粉仓：

2、拿出显影组件：松动显影组件螺丝（就是正对着你的那颗），就可以将显影组件全部拉出来。注意此时不能倾斜，里面有载体，斜很了会倒出来的。拆下5个螺丝。你会看见内有螺旋型的塑料体,是搅动载体用的.把里面的粉末全部倒出来，把磁辊上的清除干净，然后倒入新的载体，安装好螺丝。

3、拿出鼓架,这一步骤没有螺丝。

4、这时你找到硒鼓架的一侧写有LOCK字样的一端，在鼓芯没有齿轮的那面。用镊子伸进两孔中往LOCK箭头所指的反方向转一下就能卸下中间的绿色的硒鼓芯。用刷子清理复印机内部及空的硒鼓鼓架。然后安装上新的鼓芯后，再拆开硒鼓芯的遮光包装，马上装回复印机。再放回显影组件，及粉仓。

软件工程代码总结篇6

总结：

圆：

_root.createEmptyMovieClip(“MC”,1);

MC._x = 200;

MC._y = 150;

var R = 60;

MC.moveTo(R*Math.cos(0),R*Math.sin(0));

MC.lineStyle(2);

for (n=1; n < 360; n++) {

var angle = n*Math.PI/180;

var tox = R*Math.cos(angle);

var toy = R*Math.sin(angle);

MC.lineTo(tox,toy);

}

椭圆：

_root.createEmptyMovieClip(“MC”,1);

MC._x = 200;

MC._y = 150;

var W = 50;

var H = 30;

MC.moveTo(W*Math.cos(0),H*Math.sin(0));

MC.lineStyle(2);

for (n=1; n < 360; n++) {

var angle = n*Math.PI/180;

var tox = W*Math.cos(angle);

var toy = H*Math.sin(angle);

MC.lineTo(tox,toy);

}

螺旋线：

_root.createEmptyMovieClip(“MC”,1);

MC._x = 200;

MC._y = 150;

var R = 10;

var A = 3;

MC.moveTo(0,0);

MC.lineStyle(2);

for (n=1; n < 360; n++) {

var angle = A*n*Math.PI/180;

var tox = angle*R*Math.cos(angle);

var toy = angle*R*Math.sin(angle);

MC.lineTo(tox,toy);

}

多边型：

_root.createEmptyMovieClip(“MC”,1);

MC._x = 200;

MC._y = 150;

var R = 50;

var sides = 5;

var angle = (360*Math.PI/180)/sides;

var MA:Array = new Array;

for (i=0; i <= sides; i++) {

MA[i] = i*angle;

}

MC.moveTo(R*Math.cos(MA[0]),R*Math.sin(MA[0]));

MC.lineStyle(2);

for (n=1; n <= sides; n++) {

var tox = R*Math.cos(MA[n]);

var toy = R*Math.sin(MA[n]);

MC.lineTo(tox,toy);

}

补充：

长方形：

_root.createEmptyMovieClip(“MC”,1);

MC._x = 200;

MC._y = 150;

var R = 60;

MC.moveTo(0,0);

MC.lineStyle(2);

MC.lineTo(R*2,0);

MC.lineTo(R*2,R);

MC.lineTo(0,R);

MC.lineTo(0,0);

同心圆(与圆对比)：

_root.createEmptyMovieClip(“MC”, 1);

MC._x = 200;

MC._y = 150;

var R = 30;

var layer = 5;

//圆的层数

MC.lineStyle(2);

for (i=1; i <= layer; i++) {

MC.moveTo(i*R*Math.cos(0), i*R*Math.sin(0));

for (n=1; n < 360; n++) {

var angle = i*n*Math.PI/180;

var tox = i*R*Math.cos(angle);

var toy = i*R*Math.sin(angle);

MC.lineTo(tox, toy);

}

蝶形(与圆对比)：

_root.createEmptyMovieClip(“MC”, 1);

MC._x = 200;

MC._y = 150;

var R = 60;

MC.moveTo(R*Math.cos(0), R*Math.sin(0));

MC.lineStyle(2);

for (n=1; n < 360; n++) {

var angle = n*Math.PI/180;

tox = R*Math.cos(angle);

toy = R*Math.sin(angle*2);

MC.lineTo(tox, toy);

}

多棱形(与圆对比)：

_root.createEmptyMovieClip(“MC”, 1);

MC._x = 200;

MC._y = 150;

var sides = 5;

//棱数:应为奇数

var R = 100;

MC.moveTo(R*Math.cos(0), R*Math.sin(0));

MC.lineStyle(2);

for (n=1; n < 360; n++) {

var angle = n*Math.PI/180;

var r = R*Math.cos(sides*angle);

tox = r*Math.cos(angle);

toy = r*Math.sin(angle);

MC.lineTo(tox, toy);

}

星形(与多边形对比)：

_root.createEmptyMovieClip(“MC”, 1);

MC._x = 200;

MC._y = 150;

var R = 50;

var sides = 5;

var angle = (360*Math.PI/180)/sides;

var MA:Array = new Array();

for (i=0; i <= sides; i++) {

MA[i] = 2*i*angle;

}

x = R*Math.cos(MA[0]);

y = R*Math.sin(MA[0]);

MC.moveTo(x, y);

MC.lineStyle(2);

for (n=1; n <= sides; n++) {

var tox = R*Math.cos(MA[n]);

var toy = R*Math.sin(MA[n]);

MC.lineTo(tox, toy);

}

心形(与圆对比)：

_root.createEmptyMovieClip(“MC”, 1);

MC._x = 200;

MC._y = 150;

var R = 60;

MC.lineStyle(2);

for (n=1; n < 360; n++) {

var angle = n*Math.PI/180;

var r = R*Math.cos(angle)-R;

tox = r*Math.cos(angle);

toy = r*Math.sin(angle);

MC.lineTo(tox, toy);

开放源代码软件成熟度评估(上) 篇7

开放源代码软件由于开发模式和运作模式的独特性，其软件带有鲜明的特点。首先是源代码的开放性，使得用户和第三方评测者可以直接通过对代码的分析了解软件内部质量情况，是一种直观、精确的评测方式;另外，开源软件独特的开发运营模式也势必影响软件的质量状况和相关的成熟度评估方法。总之，开放源代码软件成熟度的评估方法需要我们在实践中不断探索。

本文我们将对开源软件的质量评估提出一些基本的原则和方法，尝试探讨在传统软件质量评估方法的基础上如何构建适用于开源软件成熟度评估的方法模型，并描述了模型中质量属性的具体分类和定义，从而试图建立一个基本的评估参考。

2 开源软件成熟度评估的目标和价值

开源软件在桌面应用和商业应用中扮演着越来越重要的角色。开源软件成熟度评估可以为用户应用和开源软件推广带来什么呢?

(1)为最终用户或应用与服务提供商提供开放源代码软件成熟度选型参考

开放源代码软件成熟度评估的意义在于，它可以向那些希望在自己的计算机环境中使用开源系统或开源软件的用户，或是那些希望采用开源软件构造系统集成解决方案的应用服务供应商提供帮助。帮助他们选择自身需要的开源软件;在软件的功能性、安全性、可靠性等方面综合考虑与权衡;向他们的客户提供更贴切的服务。

(2)为开放源代码软件开发者提供针对软件开发的技术、管理和需求方面的参考

由于开源软件成熟度评估自身的特点，使得评估对软件设计者和开发者具有很高的参考价值。我们知道，开源软件评估中的重要特点就是对软件技术架构和技术路线的分析和评价，以及对源代码的质量和可信度进行评测。因此，评估的结果无论从宏观上还是微观上都会对软件开发起到促进作用。

(3)促进开放源代码软件的推广、应用和开源社区的正规化建设

开放源代码软件的应用与推广需要众多参与者的共同努力。开放源代码软件成熟度评估通过对在软件项目现有的组织形式、开发模式、运营模式及社区参与和商业参与等多个层面上的分析比较，找出软件在应用推广与支持上的问题和不足，提出一些合理化建议，帮助开源软件健康、可持续的发展。

3 开放源代码软件成熟度评估体系

3.1 开源软件成熟度评估模型

开源软件和传统商业软件在软件成熟度评估的方法上确实有重要的不同。传统软件由于无法了解软件内部的情况，软件的第三方评测主要依赖于黑箱测试的方法。开源软件在这方面有明显的好处。评测人员可以深入分析软件的架构和技术特点，亲自或使用代码评测软件对程序进行分析，能够发现程序中隐藏的代码错误，分析代码的复杂度、耦合性等程序特性，给开发者提供非常有价值的技术参考，帮助开发者有效地提高软件的开发质量。这一点是开源软件质量评估中最大的优势之一。当然，开放源代码成熟度评价体系可以借鉴传统软件测试评价体系的一些概念和经验。

一个开源软件成熟的评估体系包括评估规范的确立、评估环境的建立、采用何种实施策略和评估后的信息分析等几部分，如图1所示。

首先，在决定评估规范方面我们应根据被评估软件的具体情况确定评估的属性定义和质量特性标准。既根据待评软件的应用需求确定我们要评估哪些评估属性，这些应用属性取值或评判的标准是什么，它解决了在开源软件成熟度评估中要评什么、怎么评的问题。它也是国内外相关课题最关注的议题。在这方面，我们根据评估标准的要求定义适当的质量属性和属性层级，并根据质量属性建立相应的评估软硬件环境。

评测环境的搭建：这部分工作要根据评估对象的特点确立使用哪些软硬件评测工具参与评估，实际的搭建过程可参考传统软件评测环境搭建的方法来进行。

实际评估工作：得到相应的评估属性的结果数据。具体的实施策略因项目不同而有所不同，总的来说分成两个分支进行，一个是对软件自身拥有的评估属性的客观评测，如代码评测;性能、可靠性等质量属性，称为内部属性评估。另一个是对软件外部成熟度属性的调研、评估，如社区建设、项目管理、法律风险等，称为外部属性评估。内部属性评估主要依靠各种测试手段对软件进行技术分析，代码扫描和功能测试，得出客观的测试报告。外部属性评估通过互联网搜索、在线调查甚至线下调查等手段搜集项目发展中可以表明其受关注程度或应用成熟度的相关信息，分析得出成熟度参考报告。最终的报告可以通过评分来表明软件的成熟度情况，也可不评分，只提供属性值作为后期分析的参考。

最后是根据用户的应用需求，利用评估报告综合分析找到最适合的软件方案。

3.2 开放源代码软件成熟度评估环境

开源软件成熟度评估需要建立一套完整的软硬件评估环境。建立的方法和标准与传统软件评估大致相同，本文对此不作详细阐述。软件设计评估和代码评估是开源软件成熟度评估的特色，需要评估者特别注意。

3.2.1 评测硬件环境

根据待评估开源软件的类型、用途选择搭建相应的测试环境。需要注意的是，当在多个同类型软件间进行软件选型时，评估环境必须是相同的，且必须兼顾各软件专有的特性。本文主要阐述软件评估属性模型的建立和基本内容，硬件环境的建立不做更多描述。

3.2.2 评测软件环境

代码评估工具：

代码评测是开源软件成熟度评估中的重要特色之一。它为我们提供了最准确、最直观的软件质量评价的依据。从理论上讲，用户也可以从中探知任何代码级的安全问题和可能的不良代码植入。相关代码评测的工具有多种，其中有功能复杂、强大的商业软件;还有大量针对不同语言、不同领域的开源代码检测工具和安全检测工具。

商业版软件代码评测工具，如：Klocwork、FxCop、black duck等。

开源代码检测工具，如：Flawfinder、Splint、Findbugs等。

黑箱测试工具：

黑箱测试是软件评测过程中的一个重要环节，最能够反映用户的直观体验状况。开源软件在进行黑箱测试时所涉及到的技术和评测工具与其他商业软件基本相同，本文不再详细描述。

3.3 开源软件成熟度评估规范的定义

开源软件成熟度评估中最重要的部分是评估规范的定义，即评估什么，怎么评估。按照成熟度评估的专用术语来说就是定义评估属性、属性的取值标准和评分标准。

在每一次实际的成熟度评估案例中，评估者首先要根据开源软件成熟度评估参考规范建立自己评估项目的项目评估规范。其中，主要是依据软件类型的特点、应用需求的不同建立符合用户实际要求的评估属性定义方案、属性评测方案和属性评分方案。而属性定义方案中又要确定恰当的“属性分级”、“属性类划分”、“属性取值方法”和“属性权重定义”。通过建立有针对性的项目评估规范，使最终评估结果不仅客观上取值准确，更重要的是能够选出最符合用户应用需求的软件。

3.4 开放源代码软件质量特性

按照国家标准GB/T 8566-2001，软件质量可以用下列特性来评价：功能特性、可靠特性、易用性特性、效率特性、可维护特性、可移植特性。每一个质量特性都分别与若干属性相对应。

在开放源代码软件的质量评估中，除了要考虑以上一般性软件质量特性外，我们还应看到，由于开放源码软件开发模式和商业模式的独特性，一些重要的软件自身或非自身因素也必须加入到评估的标准中来。如，技术架构;代码质量;开发模式 (代码管理(提交方式、管理工具)、组织模式、测试) ;社区建设;商业支持;法律问题。

3.5 开放源代码软件成熟度评估属性

3.5.1 评估属性类和属性的概念

软件成熟度评估属性是指软件在成熟度评估中某一具体考察对象的实际状况。对属性的评估将反映出该软件在这一评估上表现的好坏，对所有属性的综合考虑将会得出该软件成熟度的评价。

根据前一节描述的开放源代码软件质量特性的定义，我们提出与之相对应的成熟度属性定义方案，既分级定义的属性设置方案。软件质量特性的第一级对应属性类，第二级软件质量要素对应具体的成熟度评估属性。由此可见，属性类就是一些特性近似的评估属性的集合。

为什么要使用属性类对属性进行分类?这是因为，在所有的属性中，大多数属性都可以被归类描述，如，代码质量、项目管理、社区支持等。我们发现如果将每个属性不加分类放到整个属性体系中考察，属性定义本身就变得非常混乱，哪些属性需要纳入规范，哪些需要剔除，评估如何分工都会变得非常困难。此外，如果不对属性进行分类，我们也很难准确判定在权重体系中每个属性的作用大小，因而也就很难建立一套行之有效的权重标准。

从上面介绍的属性划分结构可以看出，我们的评估体系中被测要素需要根据评测粒度的不同划分层次结构，如，第一级：属性类;第二级：属性。这种分层结构的好处是评测人在定义属性规范时可根据自己的需要进行扩展，可以对属性进一步细分子属性，既扩展第三级。在评估规范中，恰当的定义软件质量属性是成熟度评估是否能够准确、公正、均衡进行的重要一环。按照评估途径、方法的不同和属性描述对象的不同，也为了能够使大家更好地理清各种成熟度属性的分类和含义，我们把各类软件成熟度属性划分为内在属性和外在属性，并分别加以描述。特别需要指出的是，我们所列的各种软件成熟度属性类及其相关的属性是开源软件成熟度评估中的一般属性，如果需要针对某一类特殊软件的特殊情况，可以定义自己的附加属性类和属性。

对于需要评分的属性评估，在对属性类和属性定义的基础上，我们给属性类和属性赋予一定权重，即加权的属性取值方案。权重的定义旨在说明各属性类和属性在评估体系中的重要程度，即，我们需要建立一种模型，让那些对成熟度影响更加重大的评估要素在体系中发挥更重要的作用。在一个同类软件的选型过程中，相应成熟度评估环境中各属性类和属性权重的定义是一个复杂和综合的过程，我们将在未来进一步研究。

评估的过程中可以对属性进行评分，从而最终产生软件整体的成熟度评分;也可不进行打分，只是将同类软件的分类属性结果进行比对，分析最适合用户应用的软件。在我们评估模型中，对每个属性评分与否是由评估者在这次评估时建立的评估规范中确定的。之所以允许评估者自行选择是否评分，主要是考虑到评估目的的不同。对于基于市场的应用选型，用户更希望量化地看到评估的结果，那么我们就可选择对属性进行评分;而对于一些社区支持下的“开源软件推荐”的成熟度评估，开源项目团队往往不希望人们将同类开源软件进行量化对比，因为这样有可能损害社区间的交流。这类评估我们可以不对属性进行评分。

3.5.2 评估属性的选取原则

选择合适的属性并能够尽量使其量化是软件成熟度评估规范中属性定义的关键。评估属性可以分为定性指标(答案为是或否的指标)和定量指标两种属性。理论上讲，为了能够科学客观地反映软件的质量特性，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特性都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。在选取评估属性时，应该把握如下原则：

●典型性

成熟度评估中选取的属性要能够充分代表软件的某项成熟度特性，范围既不能太大也不能太小。范围太大流于空泛，范围太小则会使属性缺乏代表性。

●可评测性

成熟度评估中选取的属性必须具有可评测性，也就是说属性可以通过工具测试、数据统计、数据调查等方法取得属性评测结果。属性的评测结果可以是量化的数值，可以是布尔型判断，也可以是某种结果描述(需在属性取值规范中定义)。

●简明性

成熟度属性的选取必须在具有充分代表性的基础上力求属性含义的简明化。一个属性中不能有平行的多重含义，也不能出现任何歧义。只有这样评估者才能明白无误地搞清楚他们在评估什么。

●完备性

这一原则是对所有属性整体而言的。我们定义的所有属性要能够涵盖该软件基本的成熟度特性。任何重要特性的缺失都会降低评估的公平性和准确性。此外，考虑属性定义的均衡性也是在制定属性定义规范时必须加以重视的因素，因为如果属性定义不均衡，也就是说在一般情况下，当某些领域属性定义比较多，粒度比较密集，而另一类特性领域定义属性比较少，则评测结果打分后可能会受到这种不均衡性的影响，而使分值与实际情况发生偏差。

●客观性

不言而喻，在任何软件质量评测或成熟度评估中，属性定义的客观性都是最重要的原则，它是评估结果客观公正的根本保障。在属性定义中，属性本身只反映软件的某种成熟度特性，不可带有任何倾向性，更不可对评估者进行某种诱导。

3.5.3 开源软件成熟度属性定义参考

正如成熟度评估概念中描述的，开源软件的成熟度属性包括内在属性和外在属性。内在属性之于外在属性主要是指软件自身特性所表现的成熟度状况，如，软件设计、代码质量等。而外在属性是软件自身以外对软件成熟度施加影响的相关因素，如，项目管理、社区支持等。外在属性在反映开源软件成熟度方面起到非常重要的作用。对软件外在成熟度属性的评估也包含了对项目开发、管理各个环节要素的评测，其概念有些类似CMMI (Capability Maturity Model Integration，能力成熟度模型集成)。但CMMI要求企业或项目组拥有统一的基础设施平台，而这与大多数开源软件的开发模式相违背(大多数开源软件项目采用分散式的开发方式，并且组织形式也较为松散)，因此，在开源软件开发过程评估中不能直接采用，但可借鉴其中一些方法。

注意：以下对属性类和属性的定义只是我们对一个软件基本系统研究后所列出的一般性定义，仅供使用者参考，评估人员要根据用户的需求和自身环境建立适合自己的属性定义。

以下列举一些常用的内在评估属性：

技术架构设计：分析软件的架构、模块划分、技术路线等软件设计问题。评估软件的灵活性、可扩展性、可移植性等技术特性。见表1。

代码质量：通过对开源软件代码的直接分析，评估代码的书写质量和可信度，从内部了解程序开发的质量。评估的结果生成一个代码评测报告供成熟度评估参考。代码评估可使用多种辅助工具进行，见表2。

软件易用性：一种重要的软件质量黑箱测试的指标。对普通用户提供软件使用能力重要参考，见表3。

软件可用性：另一个用户参考的重要指标。软件的可用性评测就是要对软件的可靠性、安全性及软件性能进行测试和评估，给用户进行软件选择提供参考，见表4。

开源软件成熟度外在属性包括：

项目建设与管理(人员组成、分工是否明确、开发管理、网站建设)：该领域包含了项目的组织形式、运作方式和社区的参与模式等组织特性。该软件有无专业化的市场应用推广团队。通过对软件项目运作模式的分析可以帮助我们从侧面了解软件的发展。见表5。

项目的活跃程度：大多数开源软件的项目运转情况都是对外公开的，通过对项目活跃度的各项属性的统计和分析，我们可以清楚地判断该项目的受欢迎程度、开发速度、应用支持力度等成熟度因素。见表6。

项目测试情况(有无专用测试调试工具，是否提供测试案例)：对软件的可测试性进行评估。软件项目是否有自己的独立测试组，是否提供了专门的测试环境、测试工具，是否提供相关的测试用例。见表7。

软件应用支持(社区支持，商业公司支持)：该领域包含了项目的组织形式、运作方式和社区的参与模式等组织特性。该软件有无专业化的市场应用推广团队。通过对软件项目运作模式的分析可以帮助我们从侧面了解软件的发展。见表8。

软件知识产权问题：分析开放源代码软件采用的版权协议，分析软件可能或有潜在的可能涉及其他版权协议或技术专利等问题的法律风险，评估他们是否会对软件的发展形成正面的或负面的影响。见表9。

3.5.4 开源软件成熟度属性权重定义

在有评分的项目评估规范中，我们需要为属性定义它们的权重标准。也就是说，每一个属性类都有它们的权重，权重的参照标准是属性类一级的权重定义标准;属性类中的每一个属性也都有自己的权重，它们权重的参照标准是这类的参照标准，即，一个属性的权重大小是相对于其同类属性而言的。为什么我们在评估过程中使用这种分级加权的评估模型?举例来说，从整个体系来看，就“代码质量”类中的“代码可读性”属性和社区支持类中的“文档指南”属性来衡量，很难得出哪个属性更重要或量化地来看重要多少。但在同一类中就比较好衡量，如，一般情况“代码质量”类中的“代码错误率”这一属性比同类中“代码可读性”这一属性对软件成熟度更为重要一些;而通过对各个属性类再赋予相应的权重又能比较准确的确定某一类属性整体上在体系中的重要程度，在类权重和属性权重的共同作用下，属性评分经过一定数学模式的计算将获得较为符合实际情况的软件成熟度量值。

(未完待续)

摘要：在传统商业软件质量评估模型的基础上, 结合开源软件开发模式和应用模式等方面的独特性, 总结了开源软件质量特性, 提出了开源软件成熟度评估体系模型, 并对该模型的基本操作进行具体描述。重点探讨了模型中评估属性和属性类的定义和权重标准, 以及成熟度评估的计算公式, 力图从大的框架上建立一个基于分类属性与权重的评估体系, 并通过对一些具体方法的定义, 展示一个初步的评估流程和方法。