The CISQ specification for Automated Function Points has been approved as a Supported Specification of CISQ’s co-sponsor, the Object Management Group. The preliminary draft of the specification currently undergoing finalization in OMG is available in the members area as 13-02-01 Automated Function Points. Membership in CISQ is free and we will be posting more materials related to the use of this specification over time.   This Thursday, February 14 at 10:30 AM EST (15:30 GMT) CISQ is sponsoring a Webinar on how automated Function Points will affect the future of software sizing and application development. The Featured Speaker will be David Herron, co-author of the book Function Point Analysis, co-founder of the David Consulting Group, and the technical lead of the multi-national CISQ work group that developed the Automated Function Point specification.   This specification mirrors as closely as possible the counting guidelines of the International Function Point User Group (IFPUG). However, the specification necessarily resolved any decisions involving subjective judgment in order to support automation. Therefore, although counts may … Continue reading →

This famous quote was allegedly uttered by Casey Stengel, coach of the New York Mets baseball team during their inaugural season in 1962. It became the title of a book by Jimmy Breslin documenting a season of endless bumbling by the Mets. I wonder how many senior corporate or government executives feel like Stengel when they face another IT disaster?     I just heard yet another news report about a $1 billion dollar system development failure in the U.S. government. This one was cancelled by the Air Force because after 7 years and $1B it didn’t work and showed no signs of ever working. “Can’t anybody here build these things?”   When asked how this colossal waste of taxpayer money compared with the infamous $600 toilet seats exposed by Congress years ago, U.S. Senator John McCain quipped, “Well in that case at least we got a toilet seat.” In IT you get nothing, not even something for flushing it all down!   The U.S. government seems perpetually susceptible to … Continue reading →

There’s a new strain of detection-resistant bugs going around—architecturally complex defects. The bugs are difficult to diagnose and even more difficult to remove. And they are often the most deadly.   What Are They?   An architecturally complex defect involves interactions between several components, often spread across different levels of an application. These defects reside at the subsystem or system level rather than at the code unit level. Architecturally complex defects are even more complicated if the modules or code units involved are written in different languages or reside on different technology platforms.   When tested or analyzed at the unit level, the modules or code units may show no signs of defect. The problems emerge at the subsystem or system level resulting frequently from incorrect assumptions about how different components will interact. Usually such defects can only by detected by quality techniques performed after software exits the build process, such as integration testing and static or dynamic analysis of the integrated software. Thus, quality analysis after integration must be … Continue reading →

Non-Functional App Killers   Non-functional requirements are the killers of most modern multi-language, multi-layer applications. The continuing stream of business system disasters being reported in the press are rarely the result of a functional defect. Rather they are structural flaws in the system that we cluster under the catch-all phrase, ‘non-functional requirements’. Okay, fine, but shouldn’t these structural, non-functional requirements have been stated clearly from the beginning? After all, they are requirements!   The brilliant Greek computer scientist Diomidis Spinellis warned us about this conundrum in his book Code Quality (2006, Addison Wesley): “…a failure to satisfy non-functional requirements can be critical, even catastrophic …an insecure web-server or unreliable anti-lock brake system are worse than useless…non-functional requirements are sometimes difficult to verify. We cannot write a test case to verify a system’s reliability or the absence of security vulnerabilities.”   The Challenge of Verifying Non-Functional Requirements   Quality assurance has become reasonably good at testing for the correctness of functional requirements. Such requirements can be stated clearly if the system … Continue reading →

Until its conclusion at the end of July, I was entertained by the Texas primary runoff elections. I have never seen so much mud slung in one election. I guess it replaces the other stuff politicians are famous for slinging, especially down here. However, I have no idea if my vote counted. It’s not the usual complaint that with so many voters how can my single ballot matter. No, it’s a 21st century complaint that the software in the ballot-scanning machine started glitching, and I have no idea if it ever registered my vote. Software quality is the new ‘hanging chad’.   The poor election official was trying to fix the scanner when it reported “ballot rejected” after scanning the ballot before mine. Problem was, officials at the county elections office said they had a record of the ballot coming through and being tallied correctly. The machine got so bollixed up that it refused to accept my ballot for scanning. I left the precinct hall with panicked election volunteers on … Continue reading →

Too often when I meet with executives I get confronted with, “Hey, you’re the CMM guy. How come my outsourcer is Level 5 and the software they sent me is full of bugs?”   CMM and its successor, CMMI, were never meant to be certifications for defect-free software products. Rather, they were roadmaps to help organizations adopt best software engineering practices that have proven over many decades to produce high quality software products.   There are many factors beyond process that affect the quality of a software product, such as: The skill of the developers and their knowledge of the domain of application, The novelty of the technology, The accuracy and volatility of the requirements, and The effectiveness with which a rapidly growing organization can sustain its high maturity development practices. A high maturity process can mitigate the detrimental effects of these factors, but it cannot eliminate them. Ultimately, process only provides capability—the potential to produce high quality products. The achieving the full potential of an organization’s capability only occurs … Continue reading →

It’s been several years since I was asked to become the first Director of CISQ. I’ve resisted the urge to blog in favor of driving the creation of automatable measures of software quality, presenting keynotes and webinars, consulting with IT executives, and publishing in both academic journals and the trade press. However, the almost daily outages of software-intensive systems whose damages are in the billions of $€¥₤ have convinced me that we need a blog focused software quality and directed at senior IT and business executives and managers. I will be posting weekly. The posts will alternate between advocating critical changes in our approach to ensuring the dependability, resilience, security, and cost-effectiveness of software-intensive systems, and translating the latest results from research and case studies into actionable recommendations for senior IT and software executives and managers.   I look forward to interacting with those who are affected by software quality and want to take action, or at least discuss the critical issues.   Dr. Bill Curtis Director, CISQ