With proper training and preparation, most professionals can successfully negotiate an internal assessment. This article presents practical survival tips on how to effectively participate, knowing how an assessor typically behaves during an interview and knowing how one can best demonstrate compliance to standards.

‘Scales of measure’ are fundamental to a specification method we have developed called Planguage. They are central to the definition of all scalar attributes; that is, to all the performance (especially quality attributes) and resource attributes. You can learn the art of developing your own tailored scales of measure for the performance and resource attributes, which are important to your organization or system. You cannot rely on being 'given the answer' about how to quantify. You will lose control over your current vital system performance concerns if you cannot or do not quantify the critical attributes.

Our global finance industries are in the grip of a fearsome tempest known to us as the credit crunch, triggered by bad subprime mortgages and toxic debt. Is there a lesson here for our industries and government agencies that have become reliant on software-intensive systems of systems (SISoS) and are susceptible to the potential ravages of inferior software? It is essential for the software industry to identify and tackle what I call substandard software: software life-cycle products that do not have basic quality attributes such as reliability, usability, accuracy, efficiency, adaptability, and testability. This article provides indicators and professional advice in a set of seven rules that will increase the probability of a successful software project.

Software pervades our technological society, handling our financial transactions, managing power transmission, facilitating most forms of communication, and keeping us safe. This makes defects in software one of the most potent threats to our national security, and turns identification of best practices in software development, acquisition, and long-term use the highest national priority. This article presents the best practices employed by the Ford Motor Company to develop and maintain their software assets.

For a large-scale system of systems (SoS), severe integration and run-time problems can arise due to inconsistencies, ambiguities, and gaps in how quality attributes (such as reliability) are addressed in the underlying systems. This is exacerbated in contexts where major system and software elements of the SoS are developed concurrently and oftentimes independently. Using a defense system scenario, this article outlines a uniform approach for capturing quality attribute requirements as augmentations to mission threads early in the development process and for analyzing SoS, system, and software architectures against these mission thread augmentations.

This article examines the methods for identifying and choosing a QA collaboration tool, which can serve to support and reinforce process for an organization.

Everyone knows that it’s better to “do it right the first time.” But in organizations, this requires the ability to predict outcomes of their established “best practices” as well as the ability to justify costs when it comes to applying what may be new approaches. This is just as true in software development as it is in any other business practice. This article will survey some of these best practices and present a method for evaluating the costs and benefits of applying them.

Today’s organizations must be committed to the continuous pursuit of quality improvement as a requirement for survival. Traditionally, quality and cost have been perceived as a trade-off decision. For this reason, the main purpose and benefit of measuring quality costs has been to demonstrate that improved quality and lower costs go hand-in-hand. Through collection and analysis of these quality costs, improvement is translated into a language management listens to and responds to: money. This article provides tools and techniques to help infuse cost of quality (COQ) concepts into the project team activities to promote quality improvement throughout the full project life cycle.

Many aspects of our lives are governed by large, complex systems with increasingly complex software, and the safety, security, and reliability of these systems has become a major concern. As the software in today’s systems grows larger, it has more defects, and these defects adversely affect the safety, security, and reliability of the systems. This article explains why the common test-and-fix software quality strategy is no longer adequate, and characterizes the properties of the quality strategy we must pursue to solve the software quality problem in the future.

There are two measures that have a strong influence on the outcomes of software projects: 1) defect potentials and 2) defect removal efficiency. The term defect potentials refers to the total quantity of bugs or defects that will be found in five software artifacts: requirements, design, code, documents, and bad fixes , or secondary defects. The term defect removal efficiency refers to the percentage of total defects found and removed before software applications are delivered to customers. As of 2007, the average for defect potentials in the United States was about five defects per function point. The average for defect removal efficiency in the United States was only about 85 percent. The average for delivered defects was about 0.75 defects per function point.