How to Identify Architecturally Complex Violations

Bill Dickenson, Independent Consultant, Strategy On The Web   Dr. Richard Soley, the Chariman and CEO of OMG, published a paper for CISQ titled, How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations, that outlines the software quality standard for IT business applications. The last post explored the relationship between unit and system level issues.   The logical and obvious conclusion is to dramatically increase the effort focused on detecting the few really dangerous architectural software defects. Unfortunately, identifying such ‘architecturally complex violations’ is anything but easy. It requires holistic analysis at both the Technology and System Levels, as well as a comprehensive, detailed understanding of the overall structure and layering of an application. For those needing further confirmation and explanation of such problems, the most common examples for each of the four CISQ characteristics, are described below.      #1 Reliability & Resiliency: Lack of reliability and resilience is often rooted in the “error handling.” Local, Unit Level analysis can help find missing … Continue reading

The Relationship Between Unit and System Level Issues

Bill Dickenson, Independent Consultant, Strategy On The Web   Dr. Richard Soley, the Chariman and CEO of OMG, published a paper for CISQ titled, How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations, that outlines the software quality standard for IT business applications. He classified software engineering best practices into two main categories: Rules of good coding practice within a program at the Unit Level without the full Technology or System Level context in which the program operates, and Rules of good architectural and design practice at the Technology or System level that take into consideration the broader architectural context within which a unit of code is integrated. Correlations between programming defects and production defects revealed something really interesting and to some extent, counter-intuitive. It appears that basic Unit Level errors account for 92% of the total errors in the source code. That’s a staggering number. It implies that in fact the coding at the individual program level is much weaker than expected … Continue reading

CISQ Interviewed by SD Times – Dr. Bill Curtis (CISQ) and Dr. Richard Soley (OMG) Cited

Read About CISQ’s Mission, Standards Work, and Future Direction   Tracie Berardi, Program Manager, Consortium for IT Software Quality (CISQ)   Rob Marvin published an article in the January issue of SD Times that details the work of the Consortium for IT Software Quality (CISQ). Rob interviewed Dr. Richard Soley, CEO of the Object Management Group (OMG) and Dr. Bill Curtis, Executive Director of CISQ.  The article sheds light on the state of software quality standards in the IT marketplace.   I can supplement what’s covered in the article for CISQ members.   CISQ was co-founded by the Object Management Group (OMG) and the Software Engineering Institute (SEI) at Carnegie Mellon University in 2009.   Says Richard Soley of OMG, “Both Paul Nielsen (CEO, Software Engineering Institute) and I were approached to try to solve the twin problems of software builders and buyers (the need for consistent, standardized quality metrics to compare providers and measure development team quality) and SI’s (the need for consistent, standardized quality metrics to lower the … Continue reading

CISQ to Start Work on Automated Enhancement Function Point Specification

By Tracie Berardi, Program Manager, Consortium for IT Software Quality (CISQ)   In January 2013 CISQ published a specification for Automated Function Points (AFP) that enables the automated sizing of software by function points. The spec was developed by an international team led by David Herron of the David Consulting Group. The CISQ AFP spec was designed to be as similar as possible to the IFPUG Counting Guidelines, but also to be objective so counts are consistent (the same every time) and can be automated for use in tools. You can learn more about AFP here.   In 2015 CISQ begins work on a specification for Automated Enhancement Function Points (AEFP). The existing AFP specification is not suitable for productivity analysis, as it does not solve the problem of measuring maintenance work which does not change the total number of function points even after substantial changes to the code.   The primary challenge is to identify a counting or weighting method for AEFPs that is correlated with maintenance effort – … Continue reading

How Do You Measure System Complexity?

By Tracie Berardi, Program Manager, Consortium for IT Software Quality (CISQ)   Chris Kohlhepp proposed the Law of Tangental Complexity in an article he wrote on the complexity of large scale systems. He explains: To successful systems we add functionality, inter-dependencies, and layers of abstraction. Pressures exist to continue adding value. Over time systems become so complex that they eventually reach a “cognitive horizon,” i.e. a psychological limit on the ability of humans to understand the complexity of the system. We may add lateral breadth of functionality to the system (tangent to the cognitive horizon), but in time, control is lost and TECHNICAL DEBT ensues.    Image credit: Chris Kohlhepp, Law of Tangental Complexity   As steps are taken to make the system manageable – refactoring, and perhaps the hiring of new staff – the system will again find itself nearing an even greater cognitive horizon. “Recruiting more exceptionally talented engineers who can cope with the cognitive horizon of the system proves less fruitful upon later iterations of this cycle,” … Continue reading

Software Risk Management

By David Gelperin, CTO, ClearSpecs Enterprises   40-60% of larger projects fail. Fewer smaller projects fail. Therefore, do smaller projects.   It’s safer to do projects you have done successfully before, e.g., build another ecommerce website. Therefore, repeat successful projects.   If you must do something larger and unfamiliar, identify its hazards and how you plan to mitigate them.   Functions are the goals that customers care about and focus on. Developers are told to focus on customer value. Qualities like security, privacy, reliability, and robustness are goals that customers rarely think about.    Functions are easy. Qualities are hard. When system failures make the news, e.g., security breaches, it is rarely because of a functional failure. Qualities are commonly missing from software estimates and inadequately supported in operational software.    Quality may be free, but qualities need investment. Providing a quality is nothing like providing a function. Qualities are dangerous because they are unfamiliar and out of focus.   Current Agile development ignores qualities or treats them like functions. … Continue reading

The Other Requirements

By David Gelperin, CTO, ClearSpecs Enterprises   Bob, the developer, is excited. This is his first assignment with his new employer and he really wants to show them what he can do. They are asking him to develop a “make a hotel reservation” function and he is listening carefully to understand exactly what they want. He has done something similar, except for rental cars. He asks a few clarifying questions and feels fortunate that they asked him to do something he is familiar with.   He heads back to his office to develop an estimate and then tells Sue, his supervisor, that he is ready to begin work. When he meets with Sue, she asks if he has included the relevant “crosscutting requirements” in his estimates. Bob is not sure, because he doesn’t understand what she is asking.   She explains that understanding the domain function is important, but its associated crosscutting requirements need to be understood as well and factored into estimates. Crosscutting requirements constrain multiple domain functions or … Continue reading

Seeking Beta Sites for Quality-First Agile Development

By David Gelperin, CTO, ClearSpecs Enterprises   Seeking sites to refine and use a hybrid Agile process containing two phases. The second phase is “pure” Agile development and focuses on user functions. The first phase (Quality-First) identifies and manages quality goals such as reliability, understandability, or response time, which matter to your application.   Quality-First contains the following steps:   1. Identify relevant quality goals and their acceptable quality levels early (workshop).   Some quality goals are universal that are relevant to most applications. These include: reliability, response time, modularity, ease of use and learning, and all basic qualities (compliance, sufficiency, understandability, and verifiability).   The remaining (nonuniversal) quality goals are reviewed to identify those which matter to your application.   <A comprehensive quality model will be supplied to speed this step>   2. Refine quality goal information and identify “quality champions” among your team.   3. Create master lists of development restrictions including quality constraints and design, coding, and verification tactics derived from your quality goals.   Each quality … Continue reading

What is Quality?

By Bill Ferrarini, Senior Quality Assurance Analyst at SunGard Public Sector, and CISQ Member   Quality is more than just a word, it’s a passion of mine.   In 1974 I was fortunate enough to experience Quality Circles. It was definitely that moment, when you realize that you can make a difference. I got into the PC software development industry in the early days, at a time when the Industry was in need of a direction, an industry crying for standards and quality. The first decade of this emerging industry was extremely tumultuous, a young industry struggling with its identity, finding the players that would shape it into what it is today, a multi-billion dollar industry.   Somewhere along the journey, quality became important to companies who developed and published software. Providing software that was relatively ‘bug free’ took the industry by storm. In the early 1980s, companies, left and right, were adopting Best Practice guidelines like ISO 9000. An entire industry of management and training in the art of … Continue reading

CISQ Seminar Presentations Now Available: Measuring and Managing Software Risk, Security, and Technical Debt, September 17, 2014, Austin, TX

By Tracie Berardi, Program Manager, Consortium for IT Software Quality (CISQ)   Hello Seminar Attendees and CISQ Members,   Last week we met in Austin, Texas for a CISQ Seminar: Measuring and Managing Software Risk, Security, and Technical Debt.    Presentations are posted to the CISQ website under “Event & Seminar Presentations.” Login with your CISQ username/password, or request a login here   The seminar was kicked off by Dr. Bill Curtis, CISQ Director, and Herb Krasner, Principal Researcher, ARiSE University of Texas. Are you looking to prove the ROI of software quality? Mr. Krasner’s presentation is exploding with helpful statistics. Dr. Israel Gat (Cutter) and Dr. Murray Cantor (IBM) went on to discuss the economics of technical liability and self-insuring software. Dr. William Nichols (SEI Carnegie Mellon) revealed results from studying the practices of agile teams. Robert Martin from MITRE, Director of the Common Weakness Enumeration (CWE), and lead on the CISQ security specification, talked about the latest advancements in fighting software security weaknesses.    Thank you for participating … Continue reading