If you're new here, subscribe to the RSS feed for updates on this topic. Or better yet, enter your email address below to get updates, news, and more!

Your email: 

News: Green Hills Software Receives 2011 Boeing Performance Excellence Award

By , on May 14th, 2012 in Aerospace, Customers, Defense, FAA, News, Partners

Green Hills Software
Providence, RI — [via] – Green Hills Software, the largest independent vendor of embedded software solutions, was presented with Boeing’s 2011 Performance Excellence Award. The Boeing Company issues the award annually to recognize suppliers who have achieved superior performance. Green Hills Software maintained a Silver composite performance rating for each month of the 12-month performance period, from Oct. 1, 2010 to Sept. 30, 2011. This year, Boeing recognized 529 suppliers who achieved either a Gold or Silver level Boeing Performance Excellence Award. Green Hills Software is one of 407 suppliers to receive the Silver level of recognition.

Green Hills Software, which supplies its INTEGRITY® family of operating systems and MULTI® development tools to Boeing, was joined by suppliers of precision parts, electronic-mechanical components, machining services, power supplies and converters, and shock and vibration isolators.

For more than a decade, Green Hills Software has provided systems for mission-critical product lines within Boeing. The contributions of Green Hills Software include software development tools, operating systems and related middleware, and certification and other consulting services.

“We are proud to be one of the software suppliers selected by Boeing for this prestigious award,” commented Dan O’Dowd, founder and chief executive officer of Green Hills Software. “Boeing’s supplier award illustrates the power of long-term partnerships in which organizations work together to ensure the optimal application of technology and expertise.”

SOURCE

Leave a comment   , , , , , , ,  
Related Posts:

Don’t be fooled by the coverage report

By , on May 7th, 2012 in Aerospace, Automotive, Avionics, FAA, FDA, Industrial, Medical Devices, Railway

Code Coverage
Last week, someone sent me a link to this paper:

In pursuit of code quality: Don’t be fooled by the coverage report

I know this is not a new paper. It’s from 2006. But my inbox is really deep!

In any event, the points made in this paper are applicable to software development and testing regardless of the industry or the language used. the paper reinforces the message that we use when introducing our VectorCAST/Cover product to potential clients. Specifically the following three points:

Code Coverage Tools are an “easy addition” to a developer’s tool kit
This is really a key point. Unlike many tools that require a change in process, code coverage tools can run silently behind the scenes while you perform all of your existing test activities. The setup of the code coverage tool can all be built into the build environment. If this is done properly testers will not even realize that they are testing a build with code coverage enabled.

There is a disconnect between coverage percentage and test quality
This is the central point of the paper. That is, that relying on the fact that you have achieve a high level of code coverage does not mean that your application has been thoroughly tested. The author uses may examples to make his point and I won’t repeat them here.

This point causes confusion with many organizations as they look to adopt code coverage for their projects. We often get asked: “what percentage of code coverage should we achieve”. As the author correctly points out, this looks at the question from the wrong side. Code Coverage should not be the goal of testing. Testing should occur in the context of proving that the application, sub-system or unit are implemented correctly. Once the correctness of the application is established then code coverage can be examined to determine if the testing is complete

What does missing code coverage tell us? Well the obvious thing that it tells us, is that part of the application has not been tested. Analysis is required to answer: “why has it not been tested”. There are three general reasons for the lack of code coverage: oversight by the testers, inadequate requirements, and dead code.

Different Code Coverage Analysis Catches Different Problems
The author uses several examples to show the deficiencies of statement coverage and branch coverage; specific poorly constructed statements and conditions that will not be exercised if you only get statement coverage or if you only get branch coverage.

This point is exactly why industries such as avionics have adopted different coverage mandates for different levels of criticality in the software being tested. For example, the MC/DC (Modified Condition / Decision Coverage) catches problems like short circuit evaluation and function calls nested in conditionals and is required for the most safety critical systems in Avionics, Railway, Medical, Automotive, and Industrial Controls.

I encourage you to read this paper, especially the hypothetical situations regarding estimating the time to modify existing code. Anyone who has been in this industry for a few years will get a chuckle out of that!

Leave a comment   , ,  
Related Posts:

“We Specialize in Everything”

By , on April 30th, 2012 in Journal Entry

Driving to work this morning I passed a billboard for a local hospital. The tag line was really funny to me:
“Specializing in everything.”

We Specialize in Everything

The message of any organization being good at everything is so unreasonable that it’s funny. Any organization that is truly exceptional understands their core competencies and they work to build their products around those capabilities. The concept of being really good at a few things applies to businesses of all sizes. When Jack Welch was at GE he used to say that he did not want to be in any business where GE could not be in the top three.

This made me think about the software tools business and VectorCAST. We have a really simple goal; constantly make our products better and focus on what we know a lot about: embedded software testing.

There was a time in the software tools business when customers wanted a single unified solution from a single vendor — kind of the IBM model. Today customers are smarter. They want best of breed point solutions for each tool with the ability of the tool to inter-operate and share data. Organizations have come to realize that no one vendor has the best technology for every aspect of software development tools.

One comment   , , ,  
Related Posts:
 
  Older Entries »