Assuring software quality assurance

The term quality assurance (or QA) has a variety of interpretations. The most common one is that it ensures that developers, testers, or independent auditors have performed some form of scrutiny on a system to validate that it will work as required. Software quality assurance is similar but applies to the code or noncode artifacts.     

Programming with assertions: a prospectus [software development]

To address the quality problem for software, developers need a technology that specializes in producing robust software. One widely used process that supports the construction of quality software is testing, which executes the program with input data or test cases, and then compares the output data to expected results. However, the transfer of techniques from research to practice has been slow because many techniques do not scale to real programs. An alternative to testing that has increasing popularity and usage entails the use of assertions to monitor the data attributes of functions or classes. Assertions are formal constraints on the behavior of a software application. Assertions can help improve software quality. To use them effectively, it's important to determine when they are valid.     

Evaluation of a program to motivate impaired driving offenders to install ignition interlocks

Approximately 30,000 alcohol ignition interlocks, which are designed to prevent the operation of a vehicle if the driver has been drinking, are in use in the US and Canada. Ignition interlock programs are also being initiated in Sweden and Australia. The best-controlled studies that are currently available suggest that ignition interlocks are effective in reducing impaired driving recidivism while on the vehicle. However, in the US, the practical effectiveness of these devices is limited because only a small number of offenders are willing to install them in order to drive legally. This paper reports on a study of a court policy that created a strong incentive for impaired driving offenders to install interlocks by making traditional penalties, such as jail or electronically monitored house arrest, the alternative to participation in an interlock program. Comparison of the recidivism rates of offenders subject to this policy with offenders in similar, nearby courts, not using interlocks, indicated that the policy was producing substantial reductions in DUI recidivism.     

Software Certification Services: Encouraging Trust and Reasonable Expectations

This paper proposes a more general acceptance of software certification that comprises two steps: first, it should certify the environment in which the software will execute, second, it should certify the software in the context of that environment. With the proposed certification, more complex single systems can be replaced with multiple simpler systems with increased reliability. A simpler system with a single party responsible for repair is far more likely to be fixed or replaced in a manageable time frame     

Toward a more reliable theory of software reliability

The notions of time and the operational profile incorporated into software reliability are incomplete. Reliability should be redefined as a function of application complexity, test effectiveness, and operating environment. We do not yet have a reliability equation that application complexity, test effectiveness, test suite diversity, and a fuller definition of the operational profile. We challenge the software reliability community to consider these ideas in future models. The reward for successfully doing so likely will be the widespread adoption of software reliability prediction by the majority of software publishers.     

Software quality's eight greatest myths

The software quality community has become too satisfied with the “state of the practice”. We face the same problems today that we did a decade ago, but now the urgency for solutions is greater. Our present dilemma can be best explained by walking through the past decade's major software quality trends and their associated myths. By myths, I refer to the claims used to support the numerous software quality “silver bullets” that flourished and faded in the past decade. Although I could add lesser items to my list, I consider the following eight as the main culprits (because these fads are hard to compare fairly and quantitatively, they appear in no particular order): (1) software process improvement and maturity; (2) formal methods; (3) programming languages and object-oriented design; (4) software metrics and measurement; (5) software standards; (6) software testing; (7) computer-aided software engineering; and (8) total quality management     

Untested software threatens infrastructures

The public needs access to information infrastructures that are reliable, secure, noninterruptible, and fault-tolerant, but the transition to paperless commerce threatens individual privacy with each transaction. Wholesale payment systems, such as the United States Federal Reserve's FedWire and automated clearing houses, move trillions of dollars over electronic networks daily. With roughly 95 percent of Defense Department communications relying on the commercial infrastructure, the US government is a major stakeholder in the security of commercial systems. The paper discusses the importance of software testing and the assessment of software liabilities     

Tough times, tough money: understanding investor speak

Economic scholars disagree over whether the US is currently in recession. Although current economic indicators suggest that the country has left recession there is still a vast depression in the telecommunications and IT sectors. I present recent lessons I have learned, and how to navigate through today's frigid economic waters in search of outside investment. I have learned a lot about how investors think and the language of investing. I discuss what I have learned about term sheets, the set of contractual rules between business owners and outside investors that outlines who gets what cash when a business, at some point, either sells out or goes public.     

The Services Paradigm: Who Can You Trust?

Today, the difference between software and services is murky in the wake of a new trend: the blending of physical and nonphysical systems. This new view of services is distinct in that it incorporates software (nonphysical), hardware (physical), and environment (physical and nonphysical). In this paper, with respect to software services, the trust in the old fashioned way is viewed: "assured reliance on the character, ability, strength, or truth of someone or something", which is very important in this new services economy and with new services technologies