Developing a usage-based software certification process

The author proposes an alternative to process-based methods of assuring software quality: a certification process that will provide product-based and trustworthy quality guarantees for commercial software packages. I call the agencies that perform such certification “software certification laboratories” (SCLs). The beauty of establishing independent SCLs is that they provide a fair playing field for each publisher, assuming that each product under review receives equal treatment     

Information and Quality Assurance: An Unsolved, Perpetual Problem for Past and Future Generations

Quality assurance is well understood in the hardware/manufacturing community but not necessarily within the software community. The meaning of Information assurance depends on who you ask; those in the computer security field interpret information assurance as the need to protect the information, those in quality assurance relate information assurance to the quality of the information. Software assurance ranks even poorer in understanding; although most would agree that it relates to quality, they would be unsure what that means. System assurance is well understood due to its basis on known systems-engineering principles, tending to emphasize the dichotomy of hardware and software concept understanding. In this issue, three articles address parts of the assurance puzzle, which includes: quality assurance, information assurance, software assurance, and system assurance. The combination of these four builds the argument for trust, which is the sole reason for building assurances. To help avoid costly mismatches, consider looking at which part of the assurance puzzle you need solved first before looking at supposed assurance solutions.     

What's in a Name? Distinguishing between SaaS and SOA

Considerable confusion arises in distinguishing between software as a service (SaaS) and service-oriented architecture (SOA). Zachman's framework can help to try to make sense of the alphabet soup of Web services and utilities that form the basis for both SOA and SaaS. The difference between SaaS and SOA is that the former is a software-delivery model whereas the latter is a software-construction model. A better way to illuminate the differences between these two concepts is to use the well-known Zachman architectural model. In this article, we briefly examine the concepts of SaaS and SOA, followed by a brief history of software architectural models. We use the Zachman model to differentiate the two architectural approaches to building software. Because the Zachman model is so intuitive, the approach we take to describe the differences between SaaS and SOA works well even with non-IT professionals.     

A meta-analysis of .08 BAC laws in 19 jurisdictions in the United States

More than a dozen studies on the effectiveness of the .08 blood alcohol concentration (BAC) laws have been published; however, those studies have varied both in the statistical methods and the type of outcome measure used, so it is difficult to integrate the findings into an overall estimate of the effectiveness of the law. This study used a consistent outcome measure, drinking drivers in fatal crashes and an identical methodology time-series analysis, to analyze the introduction of the .08 law in 18 states and the District of Columbia from 1982 to 2000. Each analysis accounted for other key safety laws (administrative license suspension/revocation and safety belt laws), as well as economic conditions that might influence the effectiveness of the .08 law. This provided 19 independent evaluations in which the effectiveness (treatment effect) of the law could be measured in the same quantitative terms. The number of drinking drivers in fatal crashes declined in 16 of the 19 jurisdictions after the .08 law was adopted. Nine of the 16 reductions were statistically significant (p < .05). The effect size combined across all 19 locations showed statistically significant decline (p < .005) of 14.8% in the rate of drinking drivers in fatal crashes after the .08 laws were introduced. The reduction was greater in states that had an administrative license suspension/revocation law and implemented frequent sobriety checkpoints. This analysis suggests that 947 lives might have been saved, had all 50 states and the District of Columbia had the .08 law throughout the year 2000.     

Vocational interests of naval aviation cadets: Final results.

As a validity study of the Kuder Preference Record, 605 cadets entering flight training were administered the inventory. "The KPR demonstrated small but statistically significant validity for prediction of all categories of attrition. However, when differences in mechanical ability were controlled, this inventory did not show a significant relationship to the pass-fail criterion." (PsycINFO Database Record (c) 2010 APA, all rights reserved)     

Applying a dynamic testability technique to debugging certain classes of software faults

Testability, the tendency for software to reveal its faults during testing, is an important issue for verification and quality assurance. But testability can also be used to good advantage as a debugging technique. Although this concept is more general, we will illustrate it with a specific example: propagation analysis.Propagation Analysis (PA) is a technique for predicting the probability that a data state error affects program output. PA is a technique that produces information about a piece of software's testability. PA bases its prediction on empirical measurement of the probability that an artificial data state error affects program output. After obtaining propagation analysis information for a program and obtaining a failure probability estimate for the program during execution we build a model that can be used to identify possible sites of missing-assignment faults of the form x f(x). Thus we can apply the testability technique PA as a debugging tool.This work supported by a National Research Council NASA-Langley Resident Research Associateship and NASA-Langley Grant NAG-1-884.     

UCITA: take the deal and run

The author is a strong advocate of responsibility and accountability for software products; he plays devil's advocate and reconsiders his stance. He examines the Uniform Computer Information Transactions Act (UCITA) of July 1999 in the USA. It is a proposed amendment to the Uniform Commercial Code that will govern most consumer software. The author's main argument is the lack of concern of software engineers for consumers     

Effects of enforcement intensity on alcohol impaired driving crashes

Background

Research measuring levels of enforcement has investigated whether increases in police activities (e.g., checkpoints, driving-while-intoxicated [DWI] special patrols) above some baseline level are associated with reduced crashes and fatalities. Little research, however, has attempted to quantitatively measure enforcement efforts and relate different enforcement levels to specific levels of the prevalence of alcohol-impaired driving.

Objective

The objective of this study was to investigate the effects of law-enforcement intensity in a sample of communities on the rate of crashes involving a drinking driver. We analyzed the influence of different enforcement strategies and measures: (1) specific deterrence – annual number of driving-under-the-influence (DUI) arrests per capita; (2) general deterrence – frequency of sobriety checkpoint operations; (3) highly visible traffic enforcement – annual number of traffic stops per capita; (4) enforcement presence – number of sworn officers per capita; and (5) overall traffic enforcement – the number of other traffic enforcement citations per capita (i.e., seat belt citations, speeding tickets, and other moving violations and warnings) in each community.

Methods

We took advantage of nationwide data on the local prevalence of impaired driving from the 2007 National Roadside Survey (NRS), measures of DUI enforcement activity provided by the police departments that participated in the 2007 NRS, and crashes from the General Estimates System (GES) in the same locations as the 2007 NRS. We analyzed the relationship between the intensity of enforcement and the prevalence of impaired driving crashes in 22–26 communities with complete data. Log-linear regressions were used throughout the study.

Results

A higher number of DUI arrests per 10,000 driving-aged population was associated with a lower ratio of drinking-driver crashes to non-drinking-driver crashes (p = 0.035) when controlling for the percentage of legally intoxicated drivers on the roads surveyed in the community from the 2007 NRS. Results indicate that a 10% increase in the DUI arrest rate is associated with a 1% reduction in the drinking driver crash rate. Similar results were obtained for an increase in the number of sworn officers per 10,000 driving-age population.

Discussion

While a higher DUI arrest rate was associated with a lower drinking-driver crash rate, sobriety checkpoints did not have a significant relationship to drinking-driver crashes. This appeared to be due to the fact that only 3% of the on-the-road drivers were exposed to frequent sobriety checkpoints (only 1 of 36 police agencies where we received enforcement data conducted checkpoints weekly). This low-use strategy is symptomatic of the general decline in checkpoint use in the U.S. since the 1980s and 1990s when the greatest declines in alcohol-impaired-driving fatal crashes occurred. The overall findings in this study may help law enforcement agencies around the country adjust their traffic enforcement intensity in order to reduce impaired driving in their community.