In July 2006, the 309th Software Maintenance Group (309th SMXG) at Hill Air Force Base, Utah was appraised at a Capability Maturity Model Integration (CMMI) Level 5. One focus project had been using the Team Software Process(TSP)SMsince 2001. TSP is generally considered a Level 5 process; however, during the preparation for the assessment, it became obvious to the team that even the stringent process and data analysis requirements of the TSP did not completely address CMMI requirements for several process areas (PAs). The TSP team successfully addressed these issues by adapting their process scripts, measures, and forms in ways that may be applicable to other TSP teams.

One of the foremost challenges facing the Chief Data Officer the need to establish a business case or ROI (return on investment) for Data Quality management or data governance initiatives. This article attempts to outline 15 principles of ROI development for data quality (DQ) projects that can be leveraged across any industry.

User interface which provides easy and effective work with the software product plays one of the crucial roles when purchasing mobile applications. This article covers the following items:
- What usability is in brief
- Basic standards of the user interface. Mobile standards
- Left-handed mode, Speed or satisfaction, Landscape mode
- General problems of mobile usability. Successful solutions
- Automation of usability testing
- Independent usability testing

The expression software quality has many interpretations and meanings. In this article, I do not attempt to select any one in particular, but instead help the reader see the underlying considerations that underscore software quality. Software quality is a lot more than standards, metrics, models, testing, etc. This article digs into the mystique behind this elusive area.

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.

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.

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.

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

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.

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.