How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations
In complex software applications, the same piece of code can be of excellent quality or highly dangerous - so, excellent code quality within an independent program does not guaranty a resilient, safe and efficient IT system. Correlations between architectural programming mistakes and production defects unveil something counter-intuitive. Studies show that basic coding errors within a program account for 92% of the total errors in source code but only account for 10% of production defects. Yet, software flaws at the Technology and System Level account for 8% of total errors, but consume over half the effort spent on fixing problems and lead to 90% of the most serious production issues. Engineering quality maturity grows exponentially with adherence to CISQ best practices.
IEEE: Using Analytics to Guide Improvement During an Agile-DevOps Transformation
Fannie Mae IT has transformed from a waterfall organization to a lean culture enabled by Agile methods and DevOps. The article discusses how analytics were used, along with challenges in selecting measures and implementing analytics in an Agile–DevOps transformation. Authors: Dr. Bill Curtis, CISQ and Barry Snyder, Fannie Mae.
The Cost of Poor Software Quality in the US: A 2018 Report
This research report concludes that poor software quality cost the U.S. upwards of $2.84 trillion dollars in 2018 taking into account losses from software failures, legacy system problems, technical debt, finding and fixing defects, and troubled or cancelled projects. The report examined how much the world is spending on IT software today and the fundamental issues causing problems. Looking backwards, legacy IT systems are holding us captive, looking forwards, technology innovations are coming faster and faster, and looking at present day, we're facing highly vulnerable and deficient systems-of-systems. The report was written by Herb Krasner, a member of CISQ’s Advisory Board and retired Professor of Software Engineering at the University of Texas at Austin. The report was commissioned by CA.
CISQ Recommendation Guide: Effective Software Quality Metrics for Use in ADM Service Level Agreements
Service Level Agreements (SLAs) are integral to Application Development and Maintenance (ADM). SLAs have been used to define the relationship between a service provider and customer since the early days of IT outsourcing. Yet many of the contracts written, even in the last five years, use fundamentally the same time-based SLAs for ADM. SLAs for responding to a high severity ticket or the turnaround on a work request are common. SLAs that contract around the quality of the actual code produced are rare in contrast. While many of the SLAs are appropriate for infrastructure, the SLAs for application software focus on relatively indirect measurements. Given the tight linkage between support costs, code quality, and subsequent risk to business, this must change.
Using Software Measurement in SLAs: Integrating CISQ Size and Structural Quality Measures into Contractual Relationships
As more critical business functions within an organization are automated, IT is under increasing pressure to govern the quality of software received from suppliers, whether they are vendors, outsourcers, or system integrators while at the same time reducing cost. Better governance requires better measurement of application size, stability and quality in all of its manifestations—functional, non-functional or structural, and behavioral. These measures are being incorporated into contracts as the equivalent of Service Level Agreements (SLAs), targets that suppliers must achieve to avoid penalties. In some cases, these SLAs involve productivity targets measured by the amount of business functionality delivered compared to the effort expended. In other cases, they involve targets for the structural attributes of an application such as security or maintainability.
Sample Acceptance Criteria with CISQ Standardized Metrics
This document contains contract language that you can use with software suppliers to establish acceptance criteria for evaluating software deliverables from a vendor. Use this language to ensure that your system’s source code is free of critical weaknesses as defined by industry standards. You as the buyer will evaluate the quality of the software prior to accepting delivery.