数据源特性对序列模式挖掘结果的影响

用IBM数据生成工具生成数据考察了客户序列数、平均序列长度、平均事务长度、项目数等数据特性对挖掘结果序列模式个数的影响,得到了单项特性对挖掘结果序列模式个数的影响模型,用以在进行正式挖掘之前,通过数据特性对挖掘结果进行初步判断。     

浅谈如何掌握邮件合并功能并发挥它的妙用

本文通过介绍Word邮件合并功能的操作步骤并掌握它学会进行知识的迁移,因不同工作岗位的需要,学会举一反三,在日常的生活工作当中,巧用Word邮件合并功能,从重复劳动中解脱。     

基于单片机的红外遥控解码滤波模块设计

本文以单片机为控制核心,利用相应的硬件滤波功能和软件滤波算法对红外遥控接收头的输出信号进行实时地动态处理,解析出真实的控制信号并输入到与BL9149相兼容的输出管脚。本红外遥控解码模块即滤除了干扰信号,提高了抗外界干扰光源的性能;同时实时操控性能达到了要求。     

民办院校数字化校园建设新思路之省钱“三板斧”

针对民办高校在数字化校园建设方面资金短缺问题,本文提出了通过用好开源软件、搞好校企合作和自行开发三种解决的办法。     

基于金属氧化物气体传感器的气味罗盘的实验分析研究

设计一种由TGS2620金属氧化物气体传感器构建的气味罗盘系统。研制了气味罗盘的信号采样系统及辅助电路。在点气源及平流环境下对该系统进行了360°静态气源定位实验,提取传感器阻值响应比为特征量,并论证了该特征量与罗盘偏转角度α的对应关系。实验表明气味罗盘对相差30°方向的气源据有较大的响应差,以响应比值为特征量进行分析能够排除同类型传感器个体差异对分析结果的影响。     

C语言源程序的自动评判系统

自动评判系统为通过编译C语言源程序生成的可执行程序创建进程,输入适当的测试数据,对输出结果与预设答案进行比较和评判。提出了通过匿名管道进行数据输入输出的实现方法,分析了自动评判机制中的主要问题及解决方法,重点对分级评判进行了探讨,进而提出了四级评判机制。     

基于MSP430的太阳光源跟踪控制系统设计

为了提高太阳能电池板的能量转换效率,提出了一种基于MSP430的太阳光源跟踪控制系统。系统设计原理采用光强比较法,硬件部分设计了光强信号采集电路、以MSP430为核心的主控制器、步进电机驱动电路等;软件部分采用模块化编程,加入数字滤波和控制算法。系统实现了刘信号采集与处理、电机驱动等模块的控制,能够快速准确跟踪太阳光源。运行实验结果表明,系统运行稳定,控制灵活,达到预期的设计目标。     

Static virtualization of C source code

Many existing systems are written in C and are not re‐entrant or thread safe. Sometimes these systems are required in a context for which they were not first designed, possibly meaning they now need to be re‐entrant. This article introduces a program that filters C source code, modifying shared resources (the global variables) to make the code re‐entrant: ‘virtualizing’ the code. The code is then compiled as normal. This approach allows programmatic virtualization with little cost at runtime. Copyright © 2007 John Wiley & Sons, Ltd.     

The effectiveness of software metrics in identifying error-prone classes in post-release software evolution process

Many empirical studies have found that software metrics can predict class error proneness and the prediction can be used to accurately group error-prone classes. Recent empirical studies have used open source systems. These studies, however, focused on the relationship between software metrics and class error proneness during the development phase of software projects. Whether software metrics can still predict class error proneness in a system’s post-release evolution is still a question to be answered. This study examined three releases of the Eclipse project and found that although some metrics can still predict class error proneness in three error-severity categories, the accuracy of the prediction decreased from release to release. Furthermore, we found that the prediction cannot be used to build a metrics model to identify error-prone classes with acceptable accuracy. These findings suggest that as a system evolves, the use of some commonly used metrics to identify which classes are more prone to errors becomes increasingly difficult and we should seek alternative methods (to the metric-prediction models) to locate error-prone classes if we want high accuracy.     

Quantifying requirements volatility effects

In an organization operating in the bancassurance sector we identified a low-risk IT subportfolio of 84 IT projects comprising together 16,500 function points, each project varying in size and duration, for which we were able to quantify its requirements volatility. This representative portfolio stems from a much larger portfolio of IT projects. We calculated the volatility from the function point countings that were available to us. These figures were aggregated into a requirements volatility benchmark. We found that maximum requirements volatility rates depend on size and duration, which refutes currently known industrial averages. For instance, a monthly growth rate of 5% is considered a critical failure factor, but in our low-risk portfolio we found more than 21% of successful projects with a volatility larger than 5%. We proposed a mathematical model taking size and duration into account that provides a maximum healthy volatility rate that is more in line with the reality of low-risk IT portfolios. Based on the model, we proposed a tolerance factor expressing the maximal volatility tolerance for a project or portfolio. For a low-risk portfolio its empirically found tolerance is apparently acceptable, and values exceeding this tolerance are used to trigger IT decision makers. We derived two volatility ratios from this model, the π-ratio and the ρ-ratio. These ratios express how close the volatility of a project has approached the danger zone when requirements volatility reaches a critical failure rate. The volatility data of a governmental IT portfolio were juxtaposed to our bancassurance benchmark, immediately exposing a problematic project, which was corroborated by its actual failure. When function points are less common, e.g. in the embedded industry, we used daily source code size measures and illustrated how to govern the volatility of a software product line of a hardware manufacturer. With the three real-world portfolios we illustrated that our results serve the purpose of an early warning system for projects that are bound to fail due to excessive volatility. Moreover, we developed essential requirements volatility metrics that belong on an IT governance dashboard and presented such a volatility dashboard.