Tag: Software Quality

In my last post, I shared my opinion on the benefits of non-representative measures for some software risk mitigation use cases. But does that mean I am always better served by non-representative measures? Of course not.

No bipolar disorder here, just a pragmatic approach to different use cases that are best handled with some adapted pieces of information.

Here we go again. You probably have heard, since it’s been reported everywhere, that American Airlines was grounded Tuesday, leaving passengers stranded for several hours due to a “computer glitch” in the reservation system. Because of the glitch, gate agents were unable to print boarding passes; and some passengers described being stuck for long stretches on planes on the runway unable to take off or, having landed, initially unable to move to a gate.

Last month, I had the opportunity to discuss the expanding threat of mobile IT security with CAST’s audience. The feedback we got was so overwhelming, I wanted to answer the questions we might have missed here on the blog. Lev already answered some of your questions in a previous post, so for my follow-up post, I’ll focus on the risks that often go ignored throughout the software development process.

Many software solutions feature the detection of duplicated source code. Indeed, this is one cornerstone of software analysis and measurement:

When my organization decided to hire a new CTO, one of his top priorities was to look through our old support contracts and “cut the fat,” as it were. It was there, among the rubble, where we found a transformational tool that we had cast aside which could help us increase our development productivity and software quality. But in learning more about this tool we found that it hadn’t failed us, but rather, we failed it!

Risk detection is about identifying any threat that can negatively and severely impact the behavior of applications in operations, as well as the application maintenance and development activity. Then, risk assessment is about conveying the result of the detection through easy-to-grasp pieces of information. Part of this activity is about highlighting what it is you’re seeing while summarizing a plethora of information. But as soon as we utter the word "summarizing," we risk losing some important context.

Risk detection is the most valid justification to the Software Analysis and Measurement activity: identify any threat that can negatively and severely impact the behavior of applications in operations as well as the application maintenance and development activity.

My six-year-old can tie her own shoes. I honestly did not realize how big of a deal that was until her teacher told me a few months ago that she had, for a short time, become the designated shoe tier in her classroom. Apparently, thanks to the advent of Velcro closures for kids’ shoes, nobody else in her kindergarten class knew how to tie their shoes.

Any advocate for better software quality knows that one of the biggest challenges is helping the CIO reach the CFO. When your team needs a budget for an important project, those conversations often break down. Thanks to the unavoidable technical complexity of IT, oftentimes the CIO might as well be speaking Esperanto to the CFO.

Who hasn’t been waking up early and staying up late to catch every second of action at the 2012 Summer Olympics in London?