当前位置：文档库 › Gp-based software quality prediction

Gp-based software quality prediction

GP-based software quality prediction

Matthew Evett https://www.wendangku.net/doc/8b14053458.html,puter Science&Engineering Florida Atlantic University

Boca Raton,Florida33431 (561)297-3459;matt@https://www.wendangku.net/doc/8b14053458.html,

Taghi Khoshgoftar https://www.wendangku.net/doc/8b14053458.html,puter Science&Engineering Florida Atlantic University

Boca Raton,Florida33431 (561)297-3994;taghi@https://www.wendangku.net/doc/8b14053458.html,

Pei-der Chien

https://www.wendangku.net/doc/8b14053458.html,puter Science&Engineering Florida Atlantic University

Boca Raton,Florida33431

chienp@https://www.wendangku.net/doc/8b14053458.html,

Edward Allen

https://www.wendangku.net/doc/8b14053458.html,puter Science&Engineering Florida Atlantic University

Boca Raton,Florida33431

allene@https://www.wendangku.net/doc/8b14053458.html,

ABSTRACT

Software development managers use software quality prediction methods to

determine to which modules expensive

reliability techniques should be applied.

In this paper we describe a genetic pro-

gramming(GP)based system for target-

ting software modules for reliability en-

hancement.The paper describes the GP

system,and provides a case study using

software quality data from two actual

industrial projects.The system is shown

to be robust enough for use in industrial

domains.

1Introduction

Highly reliable software is becoming an essential ingredient in many systems.Public safety and the fabric of modern life depend on software-intensive systems.We can ill afford for important systems to fail due to inadequate software reliabil-ity.

Correcting software faults late in the development life cycle (i.e.,after deployment into the?eld)is often very expensive. Consequently,software developers apply various techniques to discover faults early in development(Hudepohl et al.1996). These reliability improvement techniques include more rigor-ous design and code reviews,automatic test case generation to support more extensive testing,and strategic assignment of key personnel.While these techniques do not guarantee that all faults are discovered,they greatly decrease the probability of a fault going undiscovered before release.When a fault is discovered,it can be eliminated,and the repaired module possibly resubmitted for further reliability review. Unfortunately,reliability enhancement can be quite expen-sive,so these techniques usually cannot be applied to all the software modules comprising a project.Software develop-ment managers must attempt to apply reliability improvement techniques only where they seem likely to pay off,that is,to those software modules that appear likely to suffer the most problems.In this paper,we describe a genetic programming (GP)based system for targeting software modules for relia-bility enhancement.

One of the strongest criticisms of current GP research is that too much of it focuses on toy domains,that GP is not used on real-world problems.In this paper,we present industrial case studies to illustrate our methodology.We apply our GP-based system to software quality data from actual software development projects in two different industrial domains.The results demonstrate that our GP-based system does an excel-lent job of software quality prediction,and would be a useful tool for managers of large software projects.

Although genetic algorithms have been applied to software testing and software quality modeling for several years,this study is the?rst application of GP to software engineering that we know of(an extensive survey of on-line evolutionary computation and computer science bibliographies did not re-veal any similar studies).Because this study only introduces the application of GP to software engineering,we see many opportunities for future research.

2Software Quality Modeling

Our previous software quality modeling research has focused on classi?cation models to identify fault-prone and not fault-prone modules(Khoshgoftaar et al.1996a,Khoshgoftaar et al.1996b).A software development manager could use such models to target those software modules that were classi?ed as fault-prone for reliability improvement techniques. However,such models require that fault-prone be de?ned before modeling,usually via a threshold on the number of faults expected,and software development managers often do not know an appropriate threshold at the time of modeling.If the threshold is set too high,no modules may be classi?ed as

fault-prone,even though in any large project some modules are bound bene?t from reliability improvement.If,on the other hand,the threshold is set too low,more modules may be classi?ed as fault-prone than resource limitations(manpower, deadlines)will permit for reliability improvement.

In such cases,a prediction of the rank-order of modules, from the least to the most fault-prone,is more useful(Ohlsson and Alberg1996).With a predicted rank-order in hand, the manager can select,for reliability enhancement,as many modules from the top of the list as resources allow.

Our goal is to develop models that predict the relative qual-ity of each module,characterized as the module’s relative ranking among other modules in terms of the number of faults it is likely to produce.We used GP to create models that pre-dict the number of faults expected in each module,but we use these predictions only to rank the modules.Our evaluation of the quality of the generated models is based on ordinal crite-ria,rather than the amount of error in the predicted number of faults.

Most quality factors,including faultiness,are directly mea-surable only after software has been deployed.Fortunately, prior research has shown that software product and process metrics(Fenton and P?eeger1997)collected early in the soft-ware development life cycle can be the basis for reliability predictions.These metrics are quantities such as the number of lines of code,the degree of reuse,the number of faults in previous releases,etc.See Section3.1for a detailed list of the metrics used in this paper’s case studies.Our GP system uses these metrics as the basis for the models it generates.

Our case studies of the models generated by our GP system are based on actual industrial software development projects. Our case study data consisted of the software metrics for each module in these projects,as well as the number of faults de-tected in the modules after deployment.The exact methodol-ogy used by our GP system to create models on the basis of this data,and our evaluation methodology is explained below.

2.1Methodology for Evaluating the GP Sys-

tem

An observation is a software module represented by a tuple of software measurements,.The dependent variable of a model is the number of faults,,for each observation .The s-expressions resulting from our GP system are the models.Let be the estimate of by model.We

develop software quality models based on data from a com-pleted past project where measurements and the number of faults are available for each module,using this methodology: 1.Impartially split the available data into training and val-

idation data sets.

2.Run the GP system multiple times.For each run:

(a)The GP system has access only to the training data.

The best-of-run is the model returned as the result

of the run.The details of the GP process are de-

scribed in Section2.3.

(b)Use each best-of-run model to predict the number

of faults in the validation modules,and order them

accordingly.

(c)Evaluate each best-of-run model using ordinal cri-

teria(based on the dependent variable,the actual

number of faults observed after deployment,)de-

tailed in Section2.2.

3.Summarize the model evaluations over the runs for each

past project.

Part of our model evaluation(Step2c)includes a compari-son of the ordering obtained by each model to a random order-ing,and to the ordering obtained by using the actual observed faults.The?rst comparison indicates whether a GP result is really different from a random ordering result.(A random or-dering emulates a development strategy that randomly selects modules for reliability enhancement treatment,a not uncom-mon strategy in some development environments.The second comparison(i.e.,to the actual ordering)indicates how near the model is to a perfect model.

2.2Ordinal Evaluation

Each individual of our GP populations(including the best-of-runs)is a model that predicts the number of faults for any soft-ware module,given a set of software product measurements for that module.We do not expect a model’s prediction of the number of faults of each module to be perfect.In Step2b of our modeling methodology,we evaluate a model’s usefulness by its ability to approximately order modules from the most fault-prone to the least fault-prone.

According to Pareto’s Law applied to software engineer-ing,20%of the modules will typically account for about80% of the faults.These proportions were true for our case study, where more than70%of the modules had zero or only one fault.The purpose of the model should be to identify the top 20%of the fault-prone modules.Moreover,resources may be limited for reliability enhancement treatments.Thus,in this study,a manager will probably be interested in reviewing less than25%of the modules.In this context,let be manage-ment’s preferred set of cutoff percentiles of modules ranked by faults,and let be the number of percentiles in.In these terms,Pareto’s Law implies that the modules above the percentile(i.e.,the top20%of the modules)have80%of the faults.In the case study,we chose90,85,80,and75per-centiles.Another project might choose different percentiles, but this set illustrates our methodology.

Let tot be the total number of actual faults in the validation data set’s software modules.Our ordinal evaluation procedure (used in Step2c for each model)is:Given an individual,, and a validation data set indexed by:

1.Determine the perfect ranking of modules,,by order-

ing modules according to.Let be the per-centile rank of observation.

2.Construct a random ranking of the modules,.Let

be the percentile rank of observation.

3.Determine the predicted ranking,,by ordering mod-

ules according to.Let be the percentile rank of observation.

4.For each cutoff percentile value of interest,:

(a)Calculate the sum of actual faults,,in modules

above the cutoff for.

(1)

(b)Calculate the sum of actual faults,,in modules

above the cutoff for.

(2)

(c)Calculate the sum of actual faults in modules above

the cutoff,,for.

(3)

5.Calculate the percentage of total faults accounted for

by each ranking,namely,tot,tot,and tot

.Note that the?rst of these ratios provides in-sight into the importance of each percentile https://www.wendangku.net/doc/8b14053458.html,-parisons of the other ratios to the?rst indicate how ac-curately the other rankings re?ect this importance.

6.Calculate how closely the faults accounted for by the

random and model rankings match those of the perfect ranking as ratios,and.Let

(4)

The percentage of the actual faults,,for a percentile level,is our primary measure of the accuracy of each ranking.

2.3Details of GP System

Function and terminal sets The function set consists of

(5)

where,to lessen the risk of arithmetic over?ow.Divide(),exponentiation(),and natural log-arithm()are modi?ed to protected against invalid inputs. The terminal set,,consists of the available software product metric variables(the independent variables of the data sets) and the ephemeral random constant generator function,, taken from Koza(Koza1992).Initial population.We use the ramped half-and-half method(50%of individuals are created as full trees,and50% are created using the grow method).The population size is constant at individuals.The maximum depth of initial s-expression trees was6,while the minimum was3. (The depth limit for subsequent generations was17levels.) Fitness function.In some GP systems,the?tness of an in-dividual can be in?uenced by that of its ancestors,but here it is not.Thus,we omit the generation of an individual from our notation,below.

Raw?tness of individual is de?ned as a logarith-mic/exponential function of the absolute errors in predictions of faults.

raw

(6)

where is an index over all observations,,in the training data set.This functional form is a starting point for further research.Because our goal is to minimize error,we let stan-dardized?tness simply be equal to raw?tness

std raw(7) We use adjusted?tness,adj,as the?tness function in our GP system,using the usual de?nition:

adj

std

(8)

Run termination criterion.A run is terminated if an indi-vidual with adj is encountered,a“perfect”solution to the problem,or when the maximum number of generations is reached.The maximum number of generations is.

Selection and population rede?nition.The probability of cross-over is.The probability of reproduction is .The probability of mutation is.(All typical values for GP systems(Koza1992).) Reproduction.The system uses a straight?tness-proportionate method to select candidates for reproduction (i.e.,no elitism).

Cross-over.The tournament selection method is used to choose each parent for cross-over.The tournament size is individuals(Koza1994).One cross-over node in each parent’s s-expression is independently chosen using a uniform probability distribution.If cross-over creates an offspring that violates the maximum depth of tree parameter,the result is discarded and new cross-over points are chosen until a pair of valid offspring are produced.

Mutation.A straight?tness-proportionate method is used to select candidates for mutation.A mutation point is ran-domly chosen.When mutation produces a tree that violates the maximum depth of tree parameter,the result is discarded and the mutation process is repeated with the same parent un-til a valid offspring is produced.

Table1The Tableau used in the case studies.

Terminal set:Software product metrics avail-

able from each data set and,

varying over the range[0,1].

Function set:

Initialization:Ramped half-and-half.

Fitness cases:188(CCCS)and117(LTS)mod-

ule observations,each a tuple of

numeric software metrics.

Raw?tness:Log of sum of errors in the pre-

dicted number of faults(see6).

Std.?tness:same as raw?tness.

Wrapper:Ranks?tness cases on basis of

predicted number of faults.

Parameters:,.

Success Pred.:Ranking of modules obtained by

best-of-generation exactly equals

that based on actual faults.

ADFs?:No

Result designation.We used a technique called“canary functions”to limit the effect of over?tting.We detail canary functions and their ef?cacy elsewhere(Evett et al.1998). The canary function should be distinct from the?tness function,but also related toward meeting the same overall goal as the?tness function—in this case,generating a ranking of the modules that maximizes the ordinal evaluation criteria (Section2.2).For the case studies in this paper,our canary function,,was de?ned on an individual as:

avg(9) where is as de?ned in4,but evaluated over the training data set,and is the set of cutoff percentiles of interest.The averaging over the cutoff percentiles provides equal emphasis to each cutoff.The hope is that because the canary function differs from the?tness function,its value will begin to de-grade signi?cantly from the?tness function at about the time over?tting occurs.Our experiments(Evett et al.1998)have supported this hypothesis.

At the end of each generation,the canary function is eval-uated on the best-of-generation individual.The result of each run is the best-of-generation individual that obtained the high-est value for the canary function.In other words,the result of each run is the best-of-generation individual with the best per-centage of actual faults,averaged over the percentile levels of interest.We call this the result individual,.The tableau for the GP system is given in Table1.

3Case Study

Our case study consisted of evaluating the GP system on data sets from two industrial software projects.Table2Software Product Metrics

Symbol Description

Number of unique operators

Total number of operators

Number of unique operands

Total number of operands

McCabe’s cyclomatic complexity

Extended cyclomatic complexity

number of logical operators Lines of code

Executable lines of code

3.1Command,Control and Communications

System

The Command,Control and Communications System,CCCS, is a large military data communications system written in Ada.Generally,each module is an Ada package,consisting of one or more procedures.The developers had collected soft-ware product metrics from the source code of each module. The value of these metrics comprised the independent vari-able components of each observation tuple.Table2lists the software metrics used in the CCCS case study.

Note that the metrics collected for CCCS do not constitute a canonical set of software metrics—there is no such thing. Software development managers and institutions collect those metrics they feel are important.for their own domains.One of the goals of our system is to provide a methodology that can adapt to a variety of projects,and the product metrics associated with them.This study is an extension of our earlier work(Khoshgoftaar et al.1998).

We randomly selected282modules for our experiment. Applying data splitting,we impartially partitioned this data into two subsets,two thirds of the modules(188)for train-ing the GP system(the training data),and the remaining third (94modules)for validating the predictive accuracy of the best model from each run(the test data).The top20%of the mod-ules contained82.2%of the faults.

3.2Empirical Results,CCCS

We completed30runs of the GP system,using all the obser-vations in the CCCS training data set as the?tness cases.The Lil-gp system,by Zongker et al,formed the kernel of our GP system.The set of software quality models consisted of the result individual,,from each run.

We used each software quality model,,to predict the num-ber of faults,,for each module,,in the validation data set,and then we ordered the modules by these predicted num-bers,forming a ranking,.

We evaluated the rankings at cutoff percentile values of 75%,80%,85%,and90%.If a result individual,,did not obtain a minimally satisfactory percentage of actual faults, ,over the training data set,then it was not in-cluded in the analysis below.(Recall that is based on.)

Table3Statistical Summary for CCCS:

Rank%-ile

Median Mean Std Dev

9082.89%79.42%8.18%

8585.08%84.82%9.65%

8086.87%84.75%9.27%

7587.32%85.74% 5.72%

Table4CCCS.

Rank%-ile Ranking

Actual,Random,Model,

Faults,

9015223120.6

8518137153.52

8019847167.81

7521360182.63

%of Faults,tot

9063.07%9.65%50.07%

8575.10%15.43%63.70%

8082.16%19.63%69.63%

7588.38%25.01%75.78%

%of Actual,

90100%15.30%79.42%

85100%20.54%84.82%

80100%23.89%84.75%

75100%28.29%85.74%

The threshold was,which is somewhat less than the accuracy implied by Pareto’s Law.The use of the thresh-old weeded out runs that somehow got stuck in poor local minima in the search space.We made30runs of the GP sys-tem,of which5were unsatisfactory over the training data set. The evaluation below is based on the25satisfactory models applied to the validation data set.

Table3is a statistical summary over the25satisfactory models of the proportion of actual faults at each per-centile level,,calculated over the validation data set. Table4shows more detailed evaluation results averaged over the25models.(For the table,.)For compar-ison,the table includes evaluation results derived from ran-dom models and a perfect model(corresponding to ranking .)For the random model,we averaged the results of25ran-dom rankings of the observations in the validation data set to form the ranking,.

The?rst section of Table4shows the average sum of faults,“,for each range of percentiles of fault-prone modules. For example,the top10%of the modules(ranked by actual faults)account for152of the total number of faults in all mod-ules,tot.Whereas the top10%of random ranking accounts for only23of the faults,on average,the satisfactory models accounted for120.6faults.The second section of the table

shows the same data as in the?rst section,but as a propor-

tion of tot.In each of the percentile ranges studied,the models yield rankings much closer to the actual proportion of

faults than a random selection ordering.Thus,we conclude that the models are much better than a random sampling strat-

egy.The third section of the table again shows the same data

as the?rst,but as a proportion,,of the number of actual faults within each percentile(based on the actual rank-

ing).This is the“average percent of actuals”,also known

as,calculated for each ranking mode.For example,on average,the top10%of the modules in a random ranking ac-

count for only15.30%(i.e.)as many faults as are in

the top10%when ranked by the actual number of faults.On the other hand,the average GP-derived model accounts for 79.42%of the actual number.The average percent of actu-als was almost85%of a perfect model(the leftmost column) for the75,80,and85percentiles,and almost80%for the90 percentile.This indicated how closely the averaged sum of predictions for a range of percentiles approaches perfection. The results indicate that this system would be a useful tool for software quality management.

3.3Legacy Telecommunication System

The second element of our case study was a large legacy telecommunications system,LTS,written by professional pro-grammers in a large organization.This embedded computer application included numerous?nite state machines and inter-faces to other kinds of equipment.It was written in a propri-etary procedural high level language similar to Pascal.The entire system had over procedures;the portion we studied had over procedures in171modules.

The LTS data consisted of19product metrics for the mod-ules.Prior research(Khoshgoftaar et al.1996a)with this data set has shown that many of these metrics have little or no re-lation to faultiness.We used principal component analysis(a statistical method)to transform the product metrics data into ?ve new domain metrics.The value of the?ve domain met-rics and two process metrics that typically correlate strongly with faultiness(development code churn,DEV NC and de-bug code churn,FIX NC)comprised the independent variable components of each observation tuple.

We used all171modules in our experiments.As with the CCCS data set,we applied data splitting,impartially partition-ing the observations into two subsets:two thirds of the mod-ules(114)as training data,and the other third(57)as testing. The top20%of the modules contained81.7%of the faults.

3.4Empirical Results,LTS

We completed30runs of the GP system,using all the training observations of the LTS data as the?tness cases.We gen-erated the same types of rankings(,and as with the CCCS data using the software quality models resulting from the runs.We used the same criteria to exclude“unsatisfac-tory models”from the statistical analysis.Of the30models, 6did not achieve the threshold of,and so were

Table5Statistical Summary:24satisfactory LTS runs.

Rank%-ile

Median Mean Std Dev

9092.56%86.58%13.85%

8594.20%87.67%14.22%

8093.41%87.66%12.12%

7591.72%87.86%10.95% Table6Model results averaged over the24satisfactory LTS runs..

Rank%-ile Ranking

Actual,Random,Model,

Faults,

9036254598831389

8541834851136676

80463351130040617

75490031403843054

%of Faults,tot

9063.93%10.56%55.35%

8573.77%15.01%64.67%

8081.70%19.93%71.62%

7586.41%24.75%75.92%

%of Actual,

90100%16.52%86.58%

85100%20.35%87.67%

80100%24.39%87.66%

75100%28.65%87.86% excluded.

Table5is analogous to Table3,showing the proportion of actual faults at each percentile level,,calculated over the LTS validation data set.While Table6is analogous to Table4and shows a comparison of the value of the rankings obtained by the models against random and perfect rankings. The results indicate that this system would be a useful tool for software quality management.

4Conclusions

This study is the?rst that we know of to apply genetic pro-gramming to software quality modeling.In particular,GP can be used to generate software quality models whose inputs are software metrics collected earlier in development,and whose output is a prediction of the number of faults that will be dis-covered later in development or during operations.

We established ordinal evaluation criteria,rather than the amount of error,for the models produced by the GP sys-tem.This is especially appropriate for targeting reliability enhancement activities to the most fault-prone modules.

We conducted industrial case studies of software from a military communications system and a legacy telecommuni-cation system.The GP system used a conventional terminal set,function set,and?tness function(Koza1994).The per-formance of the GP-derived models,on actual industrial data, indicated that this system could be a valid software quality management tool.

Acknowledgements

This work was supported in part by a grant from Nortel.The ?ndings and opinions in this study belong solely to the au-thors,and are not necessarily those of the sponsor. References

Evett,M.P.,T.M.Khoshgoftaar,P.D.Chien and E.B.Allen (1998).Addressing over?tting in genetic programming with canary functions.Technical Report TR-CSE-98-6.

Florida Atlantic Univ..Boca Raton,FL.

Fenton,Norman E.and Shari Lawrence P?eeger(1997).Soft-ware Metrics:A Rigorous and Practical Approach.2d ed..PWS Publishing.London.

Hudepohl,John P.,Stephen J.Aud,Taghi M.Khoshgoftaar, Edward B.Allen and Jean Mayrand(1996).E MERALD: Software metrics and models on the desktop.IEEE Soft-ware13(5),56–60.

Khoshgoftaar,T.M.,E.B.Allen,N.Goel,A.Nandi and J.McMullan(1996a).Detection of software modules with high debug code churn in a very large legacy system.In:Proceedings of the Seventh International Symposium on Software Reliability Engineering.IEEE Computer Society.White Plains,NY.pp.364–371.

Khoshgoftaar,Taghi M.,Edward B.Allen,Kalai S.

Kalaichelvan and Nishith Goel(1996b).Early quality prediction:A case study in telecommunications.IEEE Software13(1),65–71.

Khoshgoftaar,Taghi M.,Matthew P.Evett,Edward B.

Allen and Pei-Der Chien(1998).An application of ge-netic programming to software quality prediction.In: Computational Intelligence and Software Engineering (Witold Pedrycz and Jim F.Peters,Eds.).World Sci-enti?c.Singapore.Forthcoming.

Koza,J.(1992).Genetic programming:on the programming of computers by means of natural selection.MIT Press.

Koza,J.(1994).Genetic programming II:Automatic Discov-ery of Reusable Subprograms.MIT Press.Cambridge, MA.

Ohlsson,Niclas and Hans Alberg(1996).Predicting fault-prone software modules in telephone switches.IEEE Transactions on Software Engineering22(12),886–894.

软件质量保证试题答案

一、判断题题1分，共20分) ( × )1、软件故障是导致软件失效的必要和充分要素。 ( √ )2、同行评审的主要目标在于检测错误、核对与标准的偏离。 ( √ )3、在任何软件机构中，定期、不定期的培训、再培训都是必须而且是必要的。 ( √ )4、在整个机构中使用基础设施防护与改进部件的主要目标是在机构积累的SQA经验基础上消除或至少降低出错率。 ( × )5、所有SQA活动和项目里程碑的完成或项目里程碑的检验是同时发生的。 ( × )6、Daniel Galin等提在20世纪50年代建立的经典质量费用模型，提供了一种以经济学观点把与产品质量保证相关的费用非类的方法学。 ( √ )7、一旦更改过的SCI替换了前面的SCI，就认为完成了软件的一个新版本。 ( √ )8、软件质量成本是一个投资问题，而不是成本问题! ( × )9、SEI CMM评估标准, ISO 9001和ISO 9000-3标准是典型的项目过程标准。 ( √ )10、软件质量保证的独特性是由软件产品不同于其他制造产品的本质决定的。二、填空题(每空1分，共20分；请把答案书写在相应横线上。) 1、软件质量工程包括软件质量保证、软件质量规划和软件质量控制三大方面。 2、McCall模型产品修改纬度的质量因素有可维护性、可测试性、灵活性。 3、面向对象模型不同于其他模型的主要特征是组件的密集重用。 4、有两种同行评审方法学：审查和走查。 5、RMA可以划分成三组类别内部风险管理措施，分包风险管理措施，顾客风险管理措施。 6、支持性质量手段有模板和检查表。 7、依据软件系统的生命周期和其他阶段，软件质量度量划分为软件过程度量和软件产品度量。 8、软件配置发布的版本有基线版本、中间版本、修订版本。 9、SQA标准被划分成软件质量管理标准，软件项目过程标准两类。 10、软件缺陷的固有特征有软件缺陷的固有性、软件缺陷的敏感性，软件缺陷的感染性。三、选择题（每小题2分，共18分） 1 软件调试的目的是（B） ( A)发现软件中隐藏的错误 (B)解决测试中发现的错误 (C)尽量不发现错误以便早日提交软件 (D)证明软件的正确性 2 .黑盒测试技术中不包括（D ）（A）等值分析测试（B）边界值分析测试（C）错误推测法（D）逻辑覆盖测试 3．（D ）是把输入条件视为“因”，把输出条件视为“果”，将黑盒看成是从因到果的网络图（A）等值分析测试（B）边界值分析测试（C）错误推测法（D）因果图 4．集成测试的测试用例是根据（C ）的结果来设计。 A.需求分析 B.源程序 C.概要设计 D.详细设计 5 CMMI中，（D ）主要致力于技术革新和优化过程的改进。

工业企业能源管理导则 GBT 15587-1995

GB/T 15587-1995 1 主题内容与适用范围本标准规定了工业企业建立能源管理系统，实施能源管理的一般要求。本标准适用于工业企业能源管理。 2 引用标准 GB 2589 综合能耗计算通则 GB 3484 企业能量平衡通则 GB 12723 产品单位产量能源消耗定额编制通则 3 能源管理系统为实施能源管理，企业应建立健全能源管理系统，包括完善组织结构，落实管理职责,配备计量器具，制定和执行有关文件，开展各项管理活动。该系统应能保证安全稳定供应生产所需能源，及时发现能耗异常情况，予以纠正，并不断挖掘节能潜力。 3.1 能源管理方针和目标 3.1.1 企业领导应根据本企业总的经营方针和目标，执行国家能源政策和有关法律、法规，充分考虑经济、社会和环境效益，确定能源管理方针。 3.1.2 应根据企业能源管理方针，制定能源管理目标。能源管理目标一般以产品单位产量能源消耗量确定，并可分别制定年度目标和长远目标。 3.1.3 企业能源管理方针和目标应以书面文件颁发，使企业所有有关人员明确，并贯彻执行。 3.2 能源管理的主要环节企业应根据自身特点，管理好以下环节： a. 能源输入； b. 能源转换； c. 能源分配和传输； d. 能源使用（消耗）； e. 能源消耗状况分析； f. 节能技术进步。 3.3 能源管理职责和权限 3.3.1 为实现能源管理目标，企业领导应负责建立、保持和完善能源管理系统，确定能源主管部门，配备具有相应技能和资格的人员，承担能源管理和技术工作，明确规定其职权范围和领导关系。 3.3.2 企业能源主管部门应系统地分析本企业能源管理各主要环节及其各项活动过程，分层次把各项具体工作任务落实到有关部门、人员和岗位。 3.3.3 企业各有关部门和人员，按照能源主管部门的协调安排，完成各项具体能源管理工作。 3.3.4 在分配落实能源管理职责的同时，要授予履行该职责所必要的权限。 3.4 能源计量器具配备与管理企业应按照国家有关规定，配备满足管理需要的能源计量器具，制定和实施有关文件，对计量器具的购置、安装、维护和定期检定实行管理，保证其准确可靠。 3.5 文件 3.5.1 为了规范和协调各项能源管理活动，应有系统地制定各种文件，严格贯彻执行。能源管理所需文件包括：管理文件、技术文件和记录。 3.5.2管理文件 3.5.2.1 管理文件是对能源管理活动的原则、职责权限、办事程序、协调联系方法、原始记录要求等所作的规定。如：管理制度、管理标准及各种规定等。

陕西师范大学现代教育技术傅钢善(最完整版)期末复习重点

陕西师范大学现代教育技术期末复习（按章节）第一章教育技术概述【名词解释】教育技术（AECT'1994定义）：教育技术是关于学习过程和学习资源的设计、开发、运用、管理和评价的理论与实践。现代教育技术：是以计算机为核心的信息技术在教育、教学中的运用（何克抗1999）。一方面，现代教育技术以现代信息技术的开发、应用为核心；另一方面，现代教育技术并不忽视或抛弃对传统媒体的开发与应用。信息素养：包含技术和人文两个层面的意义：在技术层面上，信息素养反映的是人们搜索、鉴别、筛选、利用信息的能力，以及有效的在教学过程中使用信息技术的技能；从人文层面上看，信息素养则反映了人们对于信息的情感、态度和价值观，它建立在技术层面的基础之上，涉及独立学习、协同工作、个人和社会责任等各个方面的内容。【知识点】教育技术是除教师、学生、教材等传统教学过程基本要素之外的第四要素。教育技术的研究对象是资源和过程。教育技术的研究内容是学习过程和学习资源的设计、开发、运用、管理和评价等五个方面。教育技术发源于美国。我国教育部于2004年12月正式颁布了《中小学教师教育技术能力标准（试行）》。包括“教学人员教育技术能力标准”“管理人员教育技术能力标准”“技术人员教育技术能力标准”三个部分。其内容均涉及意识与态度、知识与技能、应用与创新、社会责任四个方面。【简答】教育技术的内涵？（1）教育技术是一门理论与实践并重的学科（2）学习过程是教育技术研究和实践的对象（3）学习资源是优化学习过程的必要条件教育技术的发展趋势？（1）教育技术作为交叉学科的特点将日益突出（2）教育技术将日益重视实践性和支持性研究（3）教育技术将日益关注技术环境下的学习心理研究（4）教育技术的手段将日益网络化、智能化、虚拟化信息技术与课程整合的概念？信息技术与课程整合将改变教学结构。北京师范大学何克抗教授认为，信息技术与课程整合的本质与内涵是要求在先进的教育思想、理论，尤其是“主导——主体”教学理论的指导下，把以计算机及网络为核心的信息技术作为促进学生自主学习的认知工具与情感激励工具、丰富教学环境的创设工具，并将它们全面应用到各学科教学过程中，使各种教学资源、各个教学要素和教学环节，经过整理、组合、相互融合，在整体优化的基础上产生聚集效应，从而促进传统教学方式的根本变革，也就是促进以教师为中心的教学结构与教学模式的变革，从而达到培养学生创新精神与实践能力的目标。 ?不同观点之间的共性：信息技术与课程整合是指把信息技术作为工具融入教学工程，达到对某一学科或课程学习的改善。谈谈你对于信息技术与课程整合目标的认识？根本目标是培养学生解决问题的能力，实现面向时代发展的创新人才的培养。（1）充实、拓展课程的学习内容，促进创新人才的培养。（2）培养学生解决问题的能力，提高学生的信息素养。第二章教与学的理论【名词解释】

中国大学软件报告专业大学排名和大学名单.doc

2019年中国大学软件工程专业大学排名和大学名单中国大学软件工程专业大学排名和大学名单在最新公布的中国校友会网中国大学软件工程专业大学排名和大学名单中，北京大学、清华大学、国防科学技术大学的软件工程专业荣膺中国六星级学科专业，入选中国顶尖学科专业，位居全国高校第一；浙江大学、北京航空航天大学、华东师范大学的软件工程专业荣膺中国五星级学科专业美誉，跻身中国一流学科专业。上海交通大学、复旦大学、武汉大学、南京大学、吉林大学、中山大学、华中科技大学、四川大学、中国科学技术大学、山东大学、西安交通大学、哈尔滨工业大学、同济大学、天津大学、东南大学、湖南大学、西北工业大学、大连理工大学、北京理工大学、重庆大学、东北大学、西北大学、苏州大学、南京航空航天大学、北京邮电大学、北京工业大学、解放军理工大学等高校的软件工程专业入选中国四星级学科专业，跻身中国高水平学科专业。 2014中国大学软件工程专业排行榜名次一级学科学科专业星级学科专业层次学校名称2014综合排名办学类型办学层次1软件工程6星级中国顶尖学科专业北京大学1中国研究型中国顶尖大学1软件工程6星级中国顶尖学

科专业清华大学2中国研究型中国顶尖大学1软件工程6星级中国顶尖学科专业国防科学技术大学中国研究型中国一流大学4软件工程5星级中国一流学科专业浙江大学6中国研究型中国一流大学4软件工程5星级中国一流学科专业北京航空航天大学21中国研究型中国一流大学4软件工程5星级中国一流学科专业华东师范大学24中国研究型中国一流大学7软件工程4星级中国高水平学科专业上海交通大学3中国研究型中国一流大学7软件工程4星级中国高水平学科专业复旦大学4中国研究型中国一流大学7软件工程4星级中国高水平学科专业武汉大学5中国研究型中国一流大学7软件工程4星级中国高水平学科专业南京大学8中国研究型中国一流大学7软件工程4星级中国高水平学科专业吉林大学9中国研究型中国一流大学7软件工程4星级中国高水平学科专业中山大学10中国研究型中国一流大学7软件工程4星级中国高水平学科专业华中科技大学12中国研究型中国一流大学7软件工程4星级中国高水平学科专业四川大学13中国研究型中国一流大学7软件工程4星级中国高水平学科专业中国科学技术大学14中国研究型中国一流大学7软件工程4星级中国高水平学科专业山东大学16中国研究型中国一流大学7软件工程4星级中国高水平学科专业西安交通大学18中国研究型中国一流大学7软件工程4星级中国高水平学科专业哈尔滨工业大学20中国研究型中国一流大学7软件工程4星级中国高水平学科专业同济大学22中国研究型中国一流大学7软件工程4星级中国高水平学科专业天津大学23中国研究型中国一流大学7软件工程4星级中国高水平学科专业东南大学25中国研究型中国一流大学7软件工程4星级中国高水平学科专业湖南大学28中国研究型中国高水平大学7软件工程4星级中国高水平学

(能源化工行业)工业企业能源管理体系实施指南

（能源化工行业）工业企业能源管理体系实施指南

工业企业能源管理体系实施指南 1范围本标准为以下对象提供实施指南： a）应用DB37/T1013-2009的工业企业。 b）其他相关方。 2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本〈包括所有的修改单〉适用于本文件。GB17167用能单位能源计量器具配备和管理通则 DB37/TIOU-2009工业企业能源管理体系要求 3术语和定义 DB37/T1013-2009确立的术语和定义适用于本文件 4能源管理体系要求 4.1总要求用能单位应将能源管理体系作为企业管理的壹部分，根据其规模、性质和能力等状况确定能源管理体系边界，边界范围内的能源利用和管理活动应符合DB37/T1013-2009的要求。建立、实施、保持和改进能源管理体系，应通过以下活动进行： a）体系策划识别评价法律法规和其他要求及贯彻执行情况；评价能源利用和管理现状；确定能源基准、标杆；识别评价能源因素；制定能源方针、目标、指标；确定能源管理职责，配备资源；建立内、外部信息交流机制；将策划的结果形成文件。 b）体系实施对实体系范围内机员实施培训执行体系文件，对能源利用过程进行控制，包括能源规划、设计、采购、贮存、加工转换、传输分配、使用、回收利用等过程；全过程监视和测量；对不符合采取纠正措施和预防措施，必要时实施应急预案。 c）体系检查和改进实施内部审核；实施管理评审；识别节能潜力，确定改进措施，提供必要资源。 4.2文件要求 4.2.1总则用能单位应通过建立适宜的文件，沟通意图、统壹行动，最终实现能源管理体系的有效运行。能源管理体系文件应系统阐述用能单位能源管理体系范围内全部能源利用和管理过程，为评价体系有效性和适宜性提供评价标准和客观证据。 a）体系策划和文件编写应紧密结合，其中: 能源方针、目标。能源方针、目标是用能单位所追求的方向和目的。能源方针应表明用能单

陕西师范大学招生计划录取人数及招生专业目录(文科理科).doc

2019年陕西师范大学招生计划录取人数及招生专业目录(文科理科) 陕西师范大学招生计划录取人数及招生专业目录(文科理科) 更新：2018-11-29 11:48:29 2019年陕西师范大学招生计划录取人数及招生专业目录(文科理科) 选择可以说在很大程度上影响着考生后半生的生活方向和轨迹，很多考生因为高考填志愿时没有足够重视，要么浪费了不少分数；要么学了不喜欢的专业，在大学里感觉“痛不欲生”。俗话说“七分考，三分报”，正是说明志愿填报的重要性。那么如何填报志愿，填报志愿时选大学应主要考虑哪些指标？其中一个重要指标就是大学招生计划人数和招生专业。今日将带你一起了解关于陕西师范大学招生计划和招生人数、陕西师范大学招生专业目录等相关知识。注：2019年陕西师范大学招生专业和招生计划人数截至发稿前官方暂未公布，所以小编先整理了2018年陕西师范大学的招生计划专业的信息。考生务必以官方发布的信息为准，本文只作参考！ 2018年陕西师范大学招生计划人数和招生专业在陕西招生计划

专业名称计划类型层次科类计划数外国语言文学类 (含英语(创新试验班),翻译)非定向本科文史15哲学非定向本科文史11日语非定向本科文史11法学非定向本科文史15行政管理非定向本科文史10新闻传播学类 (含新闻学,编辑出版学,网络与新媒体专业)非定向本科文史17公共事业管理非定向本科文史10旅游管理非定向本科文史5社会学非定向本科文史14思想政治教育 (创新试验班)非定向本科文史10历史学类 (含历史学(创新试验班),文物与博物馆学,古典文献学专业)非定向本科文史22中国语言文学类 (含汉语言文学(基地班),汉语言文学(创新试验班),秘书学,汉语国际教育专业)非定向本科文史40预科班非定向本科文史10俄语非定向本科文史10数学类 (含数学与应用数学(创新试验班)、信息与计算科学、统计学专业)非定向本科理工43心理学类 (含心理学,应用心理学专业)非定向本科理工24计算机类 (含计算机科学与技术(创新试验班)软件工程,信息管理与信息系统专业)非定向本科理工57旅游管理非定向本科理工9生物科学类 (含生物科学(基地班),生物技术,生态学专业)非定向本科理工51食品科学与工程类 (含食品科学与工程,食品质量与安全专业)非定向本科理工34物理学类 (含物理学(创新试验班)电子信息科学与技术专业)非定向本科理工22新闻传播学类 (含新闻学,编辑出版学,网络与新媒体专业)非定向本科理工

软件质量保证测试试题与答案

选择题 1．软件测试的目的是（ B ）。 A）试验性运行软件B）发现软件错误 C）证明软件正确D）找出软件中全部错误 2．软件测试中白盒法是通过分析程序的（ B ）来设计测试用例的。 A）应用范围B）内部逻辑 C）功能D）输入数据 3．黑盒法是根据程序的（C）来设计测试用例的。A）应用范围B）内部逻辑 C）功能D）输入数据 4．为了提高软件测试的效率，应该（ D ）。 A）随机地选取测试数据 B）取一切可能的输入数据作为测试数据 C）在完成编码以后制定软件的测试计划 D）选择发现错误可能性最大的数据作为测试用例 5．与设计测试用例无关的文档是（A ）。 A）项目开发计划B）需求规格说明书 C）设计说明书D）源程序 6．测试的关键问题是（ B ）。 A）如何组织软件评审 B）如何选择测试用例 C）如何验证程序的正确性 D）如何采用综合策略 7．软件测试用例主要由输入数据和（ C ）两部分组成。 A）测试计划B）测试规则 C）预期输出结果D）以往测试记录分析8．成功的测试是指运行测试用例后（ B ）。 A）未发现程序错误 B）发现了程序错误 C）证明程序正确性 D）改正了程序错误 9．下列几种逻辑覆盖标准中，查错能力最强的是（ D ）。 A）语句覆盖B）判定覆盖 C）条件覆盖D）条件组合覆盖 10．在黑盒测试中，着重检查输入条件组合的方法是（D ）。 A）等价类划分法B）边界值分析法 C）错误推测法D）因果图法 11．单元测试主要针对模块的几个基本特征进行测试，该阶段不能完成的测试是（A）。 A）系统功能B）局部数据结构 C）重要的执行路径D）错误处理 12．软件测试过程中的集成测试主要是为了发现（ B ）阶段的错误。 A）需求分析B）概要设计 C）详细设计D）编码 13．不属于白盒测试的技术是（D）。 A）路径覆盖B）判定覆盖 C）循环覆盖D）边界值分析 14．集成测试时，能较早发现高层模块接口错误的测试方法为（ A ）。 A）自顶向下渐增式测试B）自底向上渐增式测试C）非渐增式测试D）系统测试 15．使用白盒测试方法时，确定测试数据应根据（A）

企业能源管理系统综合解决方案

企业能源管理系统综合解决方案关键词：实时数据库 pSpace RTBD SCADA软件能源管理系统EMS 力控监控组态软件力控eForceCon SD 1.引言 1.1.概述在我国的能源消耗中，工业是我国能源消耗的大户，能源消耗量占全国能源消耗总量的70%左右，而不同类型工业企业的工艺流程，装置情况、产品类型、能源管理水平对能源消耗都会产生不同的影响。建设一个全厂级的集中统一的能源管理系统可以实现对能源数据进行在线采集、计算、分析及处理，从而对能源物料平衡、调度与优化、能源设备运行与管理等方面发挥着重要的作用。能源管理系统（简称EMS）是企业信息化系统的一个重要组成部分，因此在企业信息化系统的架构中，把能源管理作为MES系统中的一个基本应用构件，作为大型企业自动化和信息化的重要组成部分。 1.2 整体需求分析企业希望能够采用先进的自动化、信息化技术建立能源管理调度中心，实现从能源数据采集——过程监控——能源介质消耗分析——能耗管理等全过程的自动化、高效化、科学化管理。从而使能源管理、能源生产以及使用的全过程有机结合起来，使之能够运用先进的数据处理与分析技术，进行离线生产分析与管理。其中包括能源生产管理统计报表、平衡分析、实绩管理、预测分析等。实现全厂能源系统的统一调度。优化能源介质平衡、最大限度地高效利用能源，提高环保质量、降低能源消耗，达到节能降耗和提升整体能源管理水平的目的。 2. 设计内容与原则 2.1设计内容 ★自动化系统能源管控中心网络系统及设备系统；能源管控中心软硬件平台系统；

能源系统各站点的数据采集系统；调度及操作人员所需的人机界面系统；设备冗余，安全监测系统；历史数据海量存储及分析系统等。 ★辅助系统能源系统视频安全监控；能源系统配套报警系统；能源系统大屏幕显示系统等。 2.2设计原则 ★完善能源信息的采集、存储、管理和利用 ★规范能源系统的自动化系统设计 ★实现对能源系统采用分散控制和集中管理 ★减少能源管理环节，优化能源管理流程，建立客观能源消耗评价体系 ★减少能源系统运行成本，提高劳动生产率 ★加快能源系统的故障和异常处理，提高对全厂性能源事故的反应能力 ★通过优化能源调度和平衡指挥系统，节约能源和改善环境 ★为进一步对能源数据进行挖掘、分析、加工和处理提供条件 3.系统架构典型能源系统架构包括能源调度管理中心、通讯网络、远程数据采集单元等三级物理结构（如下图示）。

-软件质量保证计划

-软件质量保证计划 31、1目的 31、2定义 31、3参考资料32管理 32、1机构 32、2任务 42、3职责53文档 53、1基本文档 53、2其他文档 63、3文档质量的度量准则64标准、条例和约定75评审和检查76软件配置管理97工具、技术和方法98媒体控制109对供货单位的控制1010记录收集、维护和保存101 引言 1、1 目的本计划的目的在于对所开发的上海博物馆古籍数字化系统规定各种必要的质量保证措施，以保证所交付的上海博物馆古籍数字化系统能够满足项目委托书或合同中规定的各项需求，能够满足本项目总体组制定的且经领导小组批准的该软件系统需求规格说明书中规定的各项具体需求。软件开发单位在开发上海博物馆古籍数字化系统所属的各个子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可根据各自的情况对本计划作适当的剪裁，以满足特定的质量保证要求，剪裁后的计划必须经总体组批准。

1、2 定义本计划用到的一些术语的定义按GB/T11457和 GB/T12505。 1、3 参考资料GB/T11457软件工程术语GB8567 计算机软件开发规范GB8567 计算机软件产品开发文件编制指南GB/T12504 计算机软件质量保证计划规范GB/T12505 计算机软件配置管理计划规范上海博物馆古籍数字化系统配置管理计划2 管理 2、1 机构在本软件系统整个开发期间，必须成立软件质量保证小组负责质量保证工作。软件质量保证小组属总体组领导，由总体组代表、项目的软件工程小组代表、项目的专职质量保证人员、项目的专职配置管理人员以及各个子系统软件质量保证人员等方面的人员组成，由项目的软件工程小组代表任组长。各子系统的软件质量保证人员在业务上受软件质量保证小组领导，在行政上受各子系统负责人领导。软件质量保证小组和软件质量保证人员必须检查和督促本计划的实施。各子系统的软件质量保证人员有权直接向软件质量保证小组报告子项目的软件质量状况。各子系统的软件质量保证人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划的所有要求。 2、2 任务软件质量保证工作涉及软件生存周期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。因此，对新开发的或正在开发的各子系统，要按照GB8567与本计划的各项规定进行各项评审工作。软件质量保证小组要派成员参加所有的评审与检查活动。评审与检查

软件-质量保证体系

[主题] 软件质量管理保证体系文档作者：微软中国撰写时间：[发布日期] 文档状态：[状态] [单位] 2

修订记录

目录修订记录 (2) 目录 (3) 公司内部标准 (4) 1．使用范围 (4) 2．引用标准 (4) 3．定义 (4) 4. 质量管理体系 (4) 4.1软件质量管理责任分配 (4) 4.2工作产品和活动 (5) 4.3评审 (6) 4.4质量保证（QA） (8) 4.5 软件测试 (10) 4.6 配置管理 (11)

公司内部标准本标准参照CMMI3《质量管理和质量保证标准》 1．使用范围本标准作为本公司在软件项目开发、供应和维护时的质量要求，以保证产品的质量，防止不合格产品。以下详细描述了软件开发各阶段的控制手段和要求。要求质量保证贯穿各个阶段，始终保证严格实施。 2．引用标准本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产品质量。使用本文档时，请尽量参照最新版本。 3．定义产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关的文档和数据。开发：软件产品的所有活动。供方：指本公司。需方：指具体项目的需求方，即客户。质量体系：质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。 4. 质量管理体系 4.1软件质量管理责任分配

4.2工作产品和活动

4.3评审评审是以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的流程。对于任何工作产品的审计，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及陪审员若干。评审组的成员可以包括PPQA、项目组成员，但不能有作者的直接领导或者管理者。评审小组先召开一个预备，作者会针对工作产品向大家做个总体的介绍，例如讲解一下本工作产品的目标是什么，以及其相关的实现细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单。评审小组的主持人负责确定什么时间开始真正的评审会议，在预备会和正式评审会议之间，评审小组成员对工作产品进行彻底检查，并依据相关标准和准则评审工作产品。

信息工程专业介绍

信息工程专业介绍: 1．专业简介：信息技术是衡量一个国家现代化水平的重要标志，我国把信息技术列为21世纪发展战略计划的首位。信息工程是一门研究信息的产生、获取、传输、存储和显示技术的学科。信息工程专业培养在信息工程，重点是光电信息工程领域具有宽厚的理论基础、扎实的专业知识和熟练的实验技能的高级信息工程科技人才。毕业生将在光电信号的采集、传输、处理、存储和显示的科学研究、工程设计、技术开发和企业管理中展示才华。 2．主修课程：光电信息物理基础、光电子学、信号与系统、通信原理、图像处理、传感器原理技术、光电检测技术、自动控制理论、光纤通信、计算机通讯网络、工程光学、微机原理、计算机软件技术基础、计算机网络技术、计算机辅助设计、数字与模拟电子技术基础、电路基础以及有关数理基础和工程基础方面的课程。 3．毕业去向：本专业历年输送了大量优秀毕业生攻读硕士、博士学位。除此之外，主要为科研单位、高等院校、电信部门、信息产业部门、企事业单位及有关公司录用，从事光电信息工程与技术、通信工程与技术、光电信号检测、处理及控制技术等领域的研究、设计、开发应用和管理等工作。电子信息工程专业业务培养目标：业务培养目标：本专业培养具备电子技术和信息系统的基础知识，能从事各类电子设备和信息系统的研究、设计、制造、应用和开发的高等工程技术人才。业务培养要求：本专业是一个电子和信息工程方面的较宽口径专业。本专业学生主要学习信号的获取与处理、电厂设备信息系统等方面的专业知识，受到电子与信息工程实践的基本训练，具备设计、开发、应用和集成电子设备和信息系统的基本能力。电子信息工程已经涵盖很广的范围。电话交换局里怎样处理各种电话信号，手机是怎样传递我们的声音甚至图象，我们周围的网络怎么样传递数据，甚至信息化时代军队的信息传递中如何保密等知识。我们通过一些基础知识的学习认识这些东西，并能够进行维护和更先进的技术和新产品的开发。你首先要有扎实的数学知识，要学习许多电路知识，电子技术，信号与系统，计算机控制原理，信号与系统，通信原理等基本课程。自己还要动手设计、连接一些电路以及结合计算机的实验。譬如自己连接传感器的电路，用计算机自己设置小的通信系统，还会参观一些大的公司的电子和信息处理设备，对整体进行了解，理解手机信号、有线电视是如何传输的等，并能有机会在老师指导下参与大的工程的设计。随着计算机和互联网日益深入到社会生活的多个层面，社会需求量相当大。现在是一个热门专业。毕业后干什么——从事电子设备和信息系统的设计、应用开发以及技术管理等随着社会信息化的深入，各行业大都需要本专业人才，而且薪金很高。可成为：电子工程师——设计开发一些电子，通信器件，起薪一般2000元——6000元/月；项目主管—策划一些大的系统，经验、知识要求很高，起薪一般4000元/月以上；还可以继续进修成为教师，进行科研项目等专业是个好专业：适用面比较宽，和计算机、通信、电子都有交叉；但是这行偏电，因此动手能力很重要；另外，最好能是本科，现在专科找工作太难了！当然大虾除外本专业对数学和英语要求不低，学起来比较郁闷要拿高薪，英语是必需的；吃技术这碗饭，动手能力和数学是基本功当然，也不要求你成为数学家，只要能看懂公式就可以了，比如微积分和概率统计公式，至少知道是在说些什么而线性代数要求就高一些，因为任何书在讲一个算法时，最后都会把算法化为矩阵计算（这样就能编程实现了，而现代的电子工程相当一部分工作都是编程）对于动手能力，低年级最好能焊接装配一些小电路，加强对模拟、数字、高频电路（这三门可是电子线路的核心）的感性认识；工具吗就找最便宜的吧！电烙铁、万用表是必需的，如果有钱可以买个二手示波器电路图吗，无线电杂志上经常刊登，无线电爱好者的入门书对实际操作很有好处

软件测试作业及答案

第一章 1.选择题（1）软件本身的特点和目前软件开发模式使隐蔽在软件内部的质量缺陷不可能完全避免，在下列关于导致软件质量缺陷的原因的描述中，不正确的是（C） A.软件需求模糊以及需求的变更，从根本上影响着软件产品的质量 B.目前广为采用的手工开发方式难以避免出现差错 C.程序员编码水平低下是导致软件缺陷的最主要原因 D.软件测试技术具有缺陷（2）缺陷产生的原因是（D） A.交流不充分及沟通不畅、软件需求的变更、软件开发工具的缺陷 B.软件的复杂性、软件项目的时间压力 C.程序开发人员的错误、软件项目文档的缺乏 D.以上都是 2.判断题（1）缺乏有力的方法学指导和有效的开发工具的支持，往往是产生软件危机的原因之一。（√）（2）目前的绝大多数软件都不适和于快速原型技术。（√）（3）在程序运行之前没法评估其质量。（×）（4）下列哪些活动是项目探索火星生命迹象（√）向部门经理进行月工作汇报（×）开发新版本的操作系统。（√）每天的卫生保洁。（×）组织超级女声决赛。（√）一次集体婚礼。（√） 3.简答题（1）什么是软件软件经历了哪几个发展阶段答：软件是一系列按照特定顺序组织的计算机数据和指令的集合。一般来讲软件北划分为系统软件，应用软件和介于着两者之间的中间件。其中系统软件为计算机使用提供最基本的功能，但是并不是针对某一特定领域，而应用软件则恰好相反，不同的应用软件更根据用户和所服务的领域提供不同的功能。 20世纪50年代初期至60年代中期是软件发展的第一阶段（又称程序设计阶段）；第二阶段从20世纪60年代中期到70年代末期是程序系统阶段。第三阶段称为软件工程阶段，从20世纪70年代中期到80年代中期，由于微处理器的出现，分布式系统广泛应用，以软件的产品化，系列化，工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计原则，方法和标准。第四阶段是从20世纪80年代中期至今，客户端/度武器（C/S)体系结构，特别是Web技术和网络分布式对象技术法飞速发展，导致软件体系结构向更加

企业能源管理系统(EMS)解决方案系统架构

企业能源管理系统（EMS）解决方案系统架构一能源管理系统（Energy management system，简称EMS）是以帮助工业生产企业在扩大生产的同时，通过能源计划、监控、统计、消费分析、重点能耗设备管理和能源计量设备管理等多种手段，合理计划和利用能源，降低单位产品能源消耗，提高经济效益为目的信息化管控系统。罗克韦尔自动化公司的电力及能源管理系统（PEMS）; 电力管理和控制系统（PMCS）;(PMCS)电力监控系统; 在淘汰落后产能的过程中，先进节能的工业自动化技术和设备成为了企业的首选。节能减排的自动化技术除了高能效电机、变频器、过程自动化系统和能源管理系统之外，还有面向冶金、有色、电力、化工、建材、造纸六大“三高”行业治理的成套专用优化系统和专用控制装置，比如特种执行器和特种检测技术，除尘、脱硫优化控制技术，固体废物焚烧的最优控制技术，废液的检测、分离和控制技术，节能、降耗的卡边控制技术，最优燃烧控制技术，最优调速控制技术，热能转换和传递优化技术等等，这些技术也是推进我国高端工业自动化产业化的重要方面。节能减排在我国的推进离不开先进的自动化技术、产业结构调整、企业管理水平的提升。节约能源已经作为我国建立节约型社会的基本国策，对于“十一五”规划中单位GDP能耗节能减排20%的任务，企业不应该把它仅仅作为约束性指标，而是应该把节能减排融入到长远发展的战略中去，这对企业的发展无疑具有巨大的促进作用。这也是产业结构优化调整到一定程度，企业管理水平也提升到一定水平，共同作用的结果。当三者有机结合，节能减排也就会大行其道了。随着我国计算机信息技术的高速发展、计算机软件应用技术的不断普及、企业信息化建设经验的不断积累和计算机信息管理系统应用水平的提高，众多企业

软件质量保证管理规定完整版

软件质量保证管理规定 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

本文档的目的是为特定产品、项目或合同的质保工作提供指导，帮助项目组其他成员了解质量保证要素，明确质量保证活动，确定质量保证范围。本文档将规定项目质量管理员的职责和权利，资源要求，活动安排，进度，要求质量保证活动中必须生成的文档，反馈问题的方法和频度等。一、管理组织本公司的软件质量保证活动统一由质量管理员进行管理、检查与汇报，公司相关部门经理及项目中的项目经理、程序经理、开发经理、测试经理、产品经理、测试经理、用户教育经理是质量保证活动中的第一责任人。二、软件开发过程本公司的软件开发过程分为以下8个阶段：项目策划阶段、需求分析阶段、设计阶段、开发阶段、测试阶段、实施阶段、验收阶段、维护阶段，每个阶段的主要活动分别为：业务启动和项目规划、需求分析、逻辑设计和物理设计、软件开发、软件测试、系统实施及用户培训、用户试用及验收、维护，里程碑分别为：策划完成、需求明确、设计完成、开发完成、测试通过、系统上线、验收通过、合同结束。每阶段结束后，必须对相应的里程碑进行检查，方式为评审或批准。三、项目文档项目文档分为两种：管理类文档与技术类文档，所有文档必须保存于知识库及相应的VSS库中。文档共有三种状态：编制完成、审核通过、批准通过。其中管理类文档只有编制和批准两种状态，技术类文档拥有所有三种状态。所有文档必须明确说明当前文档版本号。管理类文档包含以下类型：计划、总结、报告、会议纪要、备忘录、申请等。技术类文档包含：设计文档、需求文档、测试设计文档、界面原型软件、使用手册、安装手册、技术白皮书、培训资料、源代码、软件产品等。除VSS库中的文档以外，放入知识库中的文档由部门助理统一放入，文档必须批准通过。文档的编制、审核、批准可在文档中直接写明，也可使用单独的审批文档进行说明。每个项目在不同阶段必须产生的文档如下，但不限于此： 1、项目开始前：合同、技术方案、市场立项表。以上文档存放于知识库。 2、项目策划阶段：业务启动表（EXCEL格式）、项目规划（WORD格式）、项目进度（PROJECT格式）等。必须使用规定模板编写。以上文档存放于知识库。 3、需求分析阶段：需求模型（EA格式）、软件需求规格说明书（WORD格式）、单据报表格式（EXCEL格式）、需求分析评审表（WORD格式）、需求分析计划（WORD格式和PROJECT两种格式）。必须使用规定模板编写。以上文档存放于知识库。 4、设计阶段软件开发计划（PROJECT格式）、逻辑设计（EA格式）、物理设计（格式）、设计评审表（W ORD格式），必须使用规定模板编写。物理设计存放于VSS库，其它文档存放于知识库。 5、开发阶段源代码、可安装的软件、安装手册、评审表（WORD格式）。源代码、可安装的软件存放于VS S库，其它文档存放于知识库。 6、测试阶段

软件测试技术基础教程》习题解答

第一章软件测试理论一、选择题 1.软件测试的目的是C。 A．表明软件的正确性B．评价软件质量 C．尽可能发现软件中的错误D．判定软件是否合格 2.下面关于软件测试的说法，A是错误的。 A．软件测试是程序测试 B．软件测试贯穿于软件定义和开发的整个期间 C．需求规格说明、设计规格说明都是软件测试的对象 D．程序是软件测试的对象 3.某软件公司在招聘软件评测师时，应聘者甲向公司做如下保证： ①经过自己测试的软件今后不会再出现问题； ②在工作中对所有程序员一视同仁，不会因为在某个程序员编写的程序中发现的问题多，就重点审查该程序，以免不利于团结； ③承诺不需要其他人员，自己就可以独立进行测试工作； ④发扬咬定青山不放松的精神，不把所有问题都找出来，决不罢休；你认为应聘者甲的保证B。 A．①、④是正确的B．②是正确的 C．都是正确的D．都不正确 4.软件测试的对象包括B。 A．目标程序和相关文档B．源程序、目标程序、数据及相关文档 C．目标程序、操作系统和平台软件D．源程序和目标程序 5.导致软件缺陷的原因有很多，①－④是可能的原因，其中最主要的原因包括D。 ①软件需求说明书编写的不全面，不完整，不准确，而且经常更改②软件设计说明书③软件操作人员的水平④开发人员不能很好的理解需求说明书和沟通不足 A．①、②、③B．①、③C．②、③D．①、④ 二、简答题 1．简述软件测试发展的历史及软件测试的现状。参考答案：软件测试是伴随着软件的产生而产生的。在软件行业发展初期，没有系统意义上的软件测试，更多的是一种类似调试的测试，测试用例的设计和选取也都是根据测试人员的经验随机进行的，大多数测试的目的是为了证明系统可以正常运行。到了20世纪70年代以后，很多测试理论和测试方法应运而生，逐渐形成了一套完整的体系。在产业界，从20世纪70年代后期到20世纪80年代中期，很多软件企业成立了QA或者SQA部门。后来QA的职能转变为流程监控(包括监控测试流程)，而测试(Testing)则从QA中分离出来成为独立的组织职能。到了20世纪80年代初期，一些软件测试的基础理论和实用技术开始形成，软件测试作为软件质量保证（SQA）的主要职能，包含软件质量评价的内容。软件测试已有了行业标准（IEEE/ANSI）。在我国，软件测试目前还没有形成一个真正的产业，尚处于起步阶段。但是，在国内，现在在软件测试行业中各种软件测试的方法、技术和标准都还在探索阶段。总之，国内软件测试行业与一些发达国家相比还存在一定的差距。 2.简述软件缺陷在不同阶段发现错误修复的费用。参考答案：

软件质量保证体系完整版

软件质量保证体系 HEN SyStem OffiCe room【HEN16H-HENS2AHENS8Q8-HENH1688 ] ［标题］ I」录

公司内部标准本标准参照IS09000-3《质量管理和质量保证标准第三部分：在软件开发、供应和维护中的使用指南》 1.使用范围本标准作为本公司在软件项Ll开发、供应和维护时的质量要求，以保证产品的质量，防止不合格产品。以下详细描述了软件开发各阶段的控制手段和要求。要求质量保证贯穿各个阶段，始终保证严格实施。 2.引用标准本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产品质量。使用本文档时，请尽量参照最新版本。 3.定义产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关的文档和数据。开发：软件产品的所有活动。供方：指本公司。需方：指具体项Ll的需求方，即客户。

质量体系：质量要素、各要素需要达到的IJ标以及在开发过程中必须采取的措施。 4.质量管理体系软件质量管理责任分配工作产品和活动

评审评审是以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的流程。对于任何工作产品的审计，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及陪审员若干。评审组的成员可以包括PPQA.项目组成员，但不能有作者的直接领导或者管理者。评审小组先召开一个预备，作者会针对工作产品向大家做个总体的介绍，例如讲解一下本工作产品的目标是什么，以及其相关的实现细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单。评审小组的主持人负责确定什么时间开始真正的评审会议，在预备会和正式评审会议之间，评审小组成员对工作产品进行彻底检查，并依据相关标准和准则评审工作产品。在预定时间，评审小组成员以会议形式聚在一起，依次对产品进行检查，主持人负责对整个会议的进展进行控制，记录员记录下这个过程。在工作产品中发现的每一个缺陷都会被认真记录下来，并被适当分类。会议结束后，负责人需要分析相关缺陷，找出产生此缺陷的原因并加以修正。主持人应确保所有的缺陷都会得到解决和修正。如果过程需要加以变更的话，应将相关问题移交相关的质量保证人员。

大学软件工程专业排名

大学软件工程专业排名权威排名： 2006年高校软件工程排名（开设学校：139所） 1、南京大学 2、清华大学 3、复旦大学 4、武汉大学 5、浙江大学 6、上海交通大学 7、中国科学技术大学 8、中山大学 9、华中科技大学 10、哈尔滨工业大学 11、陕西师范大学 12、吉林大学 13、东北师范大学 14、北京师范大学其他院校该专业较强的有：北京交通大学北京理工大学华东师范大学华南理工大学南开大学四川大学

天津大学西安交通大学西北工业大学厦门大学中国地质大学同济大学苏州大学重庆大学中国石油大学南京理工大学宁夏大学教高[2001]6号文：教育部、国家计委关于批准有关高等学校试办示范性软件学院的通知教育部、国家计委关于批准有关高等学校试办示范性软件学院的通知（2001年12月3日）教高〔2001〕6号为适应我国经济结构战略性调整的要求和软件产业发展对人才的迫切需要，实现我国软件人才培养的跨越式发展，教育部和国家发展计划委员会共同研究决定选择部分高等学校，

采取多项扶持政策，支持其试办示范性软件学院。这是新时期推进高等教育改革与发展的一项重要举措。经统一部署、有关高校申报和专家评审，现决定首批批准35所高等学校试办示范性软件学院。为做好示范性软件学院的建设工作，现将有关意见通知如下：一、要将建设示范性软件学院作为进入新世纪跨越式培养软件人才的重大举措落实好。《国务院关于印发鼓励软件产业和集成电路产业发展若干政策的通知》（国发[2000]18号）中明确提出通过政策引导，鼓励资金、人才等资源投向软件产业，进一步促进我国信息产业快速发展，力争到2010年使我国软件产业研究开发和生产能力达到或接近国际先进水平。实现这一政策目标，加快软件人才培养是重要保证。建设示范性软件学院是我国软件产业人才培养方面实现跨越式发展的一次重大改革尝试，旨在为我国软件产业的发展带来新的推动力。各示范性软件学院要抓住机遇，加快建设步伐，努力成为我国有重要影响的多层次实用型软件人才培养基地。二、要将建设示范性软件学院作为加大高等教育人才培养结构调整力度，推进用信息技术改造传统产业的重要举措抓好。《国民经济和社会发展第十个五年计划纲要》提出，要以信息化带动工业化，发挥后发优势，实现社会生产力的跨越式发展。各示范性软件学院要在加大软件专门人才培养力度的同时，把培养大批各类复合型软件人才作为重要任务，为用信息技术改造传统产业准备坚实的人才基础。示范性软件学院可以从所在学校二年级后在校本科生中招生；可以开展软件方向第二学士学位办学；可以招收软件方向工程硕士研究生；可直接从应届本科毕业生中招收工程硕士研究生；招生方式和规模由所在学校自主确定，国家不安排招生计划数。三、建设示范性软件学院要以进一步推进办学机制改革，主动推进国内合作办学与中外合作办学，推动产学研紧密结合为基本办学模式。可以多途径探索合作办学的管理体制与运行机制，由高等学校与国内外企业合作，拉动社会资金投入，按运作企业化、办学专业化、后勤社会化的模式兴办。示范性软件学院应把开展切实有效的产学研合作作为推进办学模式