Compuware Insight E-Zines:
Automated Software Quality Edition

Posted: 06/05/05

Welcome to Compuware Insight E-Zine, Automated Software Quality Edition, keeping you up-to-date with the latest news including product updates, user stories, event details and more.

This issue contains information on:


Customer Success Story: Driving Software Quality - Formula One Team B·A·R Honda Utilise Compuware Technology to Guarantee Quality Applications

Software quality is paramount in any business, but too often in today's pressurised business environment developers are faced with the dilemma of delivering applications either quickly or with high quality. However, for the B·A·R Honda Formula One team, compromise is not an option: the very nature of Formula One means that the highest quality applications have to be developed and delivered to the business in the shortest timescales.

A Premier Race Team
B·A·R Honda specialises in Formula One racing and first began competing in 1999. Success has grown year on year and the team came 2nd in the FIA Formula One Constructors' Championship in 2004. In January 2005, Honda Motor Co. Ltd. acquired a 45 per cent stake in B·A·R Honda alongside the major shareholder and team founder, British American Tobacco.

A High Speed Environment
Few other industries can match Formula One for complexity of the design and manufacturing process. Technology plays a pivotal role and B·A·R Honda relies on industrial-strength servers and networks in every step of the design and build process. The specifications that are set each year by the European-based Federation Internationale d'Automobiles (FIA) and Formula One Management (FOM) are general, allowing teams to create unique cars from scratch every season.

Over the course of a season, which lasts for 19 Grand Prix weekends, the volumes of data automatically collected from the B·A·R Honda cars are transmitted and sent back to team headquarters for recording and analysis. Engineers use the data to constantly optimise car design, in addition to engine, power train and suspension performance. During the season, the B·A·R Honda software engineers typically have only three days to develop software that addresses any problems arisen during races.

At the season's end, B·A·R Honda designers have just a few months of development to introduce major new systems and conduct eight to nine weeks of intensive testing. The new cars typically retain just 20 per cent of the components from the previous year's designs.

"In the Formula One environment, reliability is everything and if a car hasn't been fully tested then we won't race it because we cannot guarantee optimal performance," said Max Walshe, Chief Software Architect at B·A·R Honda. "That is why it is essential to develop high quality software first time around - always within incredibly short timescales - and software testing is a critical part of this process. The four watchwords in our development team are reliability, quality, innovation and speed."

The implications of software failure are immediate and financially severe, therefore it is vital that engineers are able to constantly gather data from the cars on the track in order to see and react to indicators of problems - e.g. an increase in engine heat - as they arise. Software engineers do not only resolve errors. They are regularly called upon by the team to deliver innovative software, such as programmes that monitor the positions of other competitors during races, to maintain competitive advantage. To fulfil these demands requires a combination of skill, experience and advanced technology.

Working with and selecting an external supplier
It is hardly surprising then that after six years, B·A·R Honda had amassed incredible volumes of code, which was continuing to increase season on season. "It is a fact of life that software has bugs, but with a limited team and ever growing demands for software development we decided that, as part of good programming practice, we should look to incorporate development tools from an external supplier into our processes," said Walshe.

Driving home the benefits
Following its evaluation of suitable products, B·A·R Honda chose to use Compuware DevPartner Studio Professional Edition - the only product on the market that could analyse multi-threaded applications. "We have certain key applications of this nature, and it is notoriously difficult to re-create problems exactly in order to fix them. With DevPartner Studio this isn't a problem as it identifies thread deadlocks and allows us to analyse potential problems before they happen," said Walshe. "In fact, we have come to realise the value this functionality to such an extent that it would now be a pre-requisite for any future programming tools."

Through its browser-based interface, DevPartner Studio delivers powerful analysis and profiling techniques to help B·A·R Honda understand how its Java code will perform before it is deployed. Performance data is easily viewed through the browser, and B·A·R Honda can perform debugging tasks quicker than ever before. It supports B·A·R Honda in delivering high quality applications that run reliably across multiple computers in its distributed environment.

"DevPartner Studio was a larger suite of productivity tools than we originally envisaged going for, but we found that several elements could deliver extra value to us," said Walshe. "For example, DevPartner Profiler has been really useful in pinpointing performance bottlenecks and verifying which code changes have improved performance. Coverage Analysis has also proven valuable in error detection."

Walshe continued: "DevPartner Studio has enabled us to do three very important things: to pinpoint and fix potential issues, to save time and improve reliability. I cannot stress how important that is in the pressurised environment of racing. Formula One has the same pressures as any business - we need to ensure that our vital software systems are performing optimally and supporting our dynamic business needs at any given moment in order to gain and maintain competitive advantage. The difference is the pace: if software failure means we are unable to race our cars, our business instantly grinds to a halt. If our product isn't performing at its best then it becomes clear to the customer - including our huge fan base across the globe - within seconds on the race track."

"That is why the B·A·R Honda software engineers have a 'get it right first time' mentality, because we really are at the sharp end of software failure. We have found that DevPartner Studio has quickly become a vital component of our software processes because it has enabled us to broaden the scope of risk analysis and defect identification as well as other issues. It has certainly been able to hold its own in an incredibly fast paced and demanding environment," concluded Walshe.

To request a free risk-free 14-day evaluation of DevPartner, please click here


Opinion Piece: Build with Quality in Mind

Week in, week out, we hear stories about problems with new IT applications. Only recently there were news reports about testing delaying NHS IT projects in the UK. Obviously this testing work has to be carried out to ensure that applications are only rolled out when they can provide the level of performance and reliability needed. However, if major problems are continually being found when applications are being tested, one has to ask whether there is a problem with the way in which applications are being developed in the first place?

As organisations look to new applications to improve organisational efficiency or competitive advantage, developers are under constant pressure to build applications quickly and cost effectively. So, as you would expect, developers have generally been focused on speed in relation to writing code and building functionality that works. What's the problem with that you might ask? On the face of it nothing. However because developers are being pressured to deliver and deliver quickly, quality is not necessarily something that will be at the forefront of their minds. We all know that doing something quickly doesn't always equal doing something well.

The problem is that developers are typically trained to construct code and functionality whereas testing professionals are trained in how to deconstruct something that a developer has built. Therefore the majority of developers will not be able to test for implications such as the network going down, or consider how changing one line of code might impact other parts of the application. Additionally, they won't be thinking about how their code handles errors. They will obviously test what they write and build to make sure it works, but very few developers have time to think about circumstances that could lead to their code or functionality failing.

Developers can't be blamed for this, they typically have not been trained or incentivised to develop with quality in mind. Today's competitive landscape, where companies are constantly striving to become leaner and more aggressive in strategy and delivery, has resulted in developers being put under constant pressure to develop faster than Jenson Button can get round a formula one track. The problem is that these factors have resulted in developers being judged and measured against how well they keep to project timelines and ultimately how quickly they can deliver the code/functionality they have been tasked with. Quality becomes a poor relation to the project deliverables.

This needs to change. However, the change will only happen if management, IT directors in particular, firstly recognise there is a problem and secondly start to understand that it is worth encouraging developers to focus on improving the quality of their code. IT directors need to take a long term view and remember that making quality improvements at the development stage is much more cost effective than reacting to problems the quality assurance team picks up, or indeed fixing a bug once the application has been deployed. They need to foster a cultural change so that developers recognise that they will not only be measured on speed, but also on consistency and quality of their code. Essentially quality targets need to be put in place for developers so that the QA team are only handed code once it is proven to be of a certain standard. So how can this work in practice?

Quality targets need to be established and quality gates need to be put in place. A quality gate is a process through which a deliverable must pass before it is accepted by developers as ready for systems testing. Developers need to assess the code they are delivering against quality targets to see if it can pass through the quality gate. If it does not meet the quality targets then the developers need to take it back for further work, otherwise it can then be passed on for systems testing. But how can quality targets be met without compromising on project deadlines? This is where structured processes and tools come in. Developers need to use these to make quality assessments and provide reports on code coverage and test results. These tools and the processes basically act as a virtual advisor to the developer so that he can always develop with quality in mind, with minimal impact to the project schedule. Outputs from such tools give an objective opinion on the overall quality of the application ensuring that consistency is applied to software quality and there is tangible evidence that a quality target has been met.

By arming developers with these processes and tools, organisations should see a decrease in development projects failing or running over budget and time. If developers can carry out thorough, timely testing on the units they produce, system testers can focus solely on testing business critical processes rather than on low-level code. Inevitably this will improve application quality and ultimately project success as systems testers will have more time to test and guarantee the quality of the high risk parts within the application.

IT directors must make these changes so that everyone involved in a development project is thinking about quality and to enable quality assurance teams to focus on de-risking applications rather than debugging them. Quality isn't something that should be thought about once an application is developed, it should be considered from the very start. If you were building a house, you'd make sure you use good quality bricks and mortar. Likewise when organisations are building applications they need to make sure they have good quality code.

To find out more about building quality into your application development process, please click here


Two Interactive Product WebEX's: The Opportunity to See DevPartner Fault Simulator and DevPartner SecurityChecker in Action

DevPartner Fault Simulator - a unique new developer tool using fault simulation to emulate real-world application errors. At this online event you will see how Fault Simulator helps test and debug error handlers when it is integrated into Visual Studio .NET. See how using fault simulation to emulate real-world application errors can enable you to work in a predictable, repeatable environment to proactively analyse and debug application error-handling code.

The demonstration is interactive and runs for approximately 60 minutes.

Topic: DevPartner Fault Simulator Demonstration
Date: Tuesday, May 10, 2005
Time: 14:00, GMT Standard Time, 15:00 CET

To attend this meeting, you must first register for it. Once you have registered for the meeting, you will receive an email message confirming your registration. This message will provide the information that you need to join the meeting.

The conference call information for the WebEX is on the registration page also.

DevPartner SecurityChecker - a powerful security analysis tool that helps quickly scan, locate and fix known and potential security vulnerabilities in ASP.NET applications. At this online event, you will learn how SecurityChecker automates detection processes through a combination of runtime, compile-time and integrity analyses that pinpoint the exact location of vulnerable source code and hard-to-find security problems.

The demonstration is interactive and runs for approximately 60 minutes.

Topic: DevPartner SecurityChecker Demonstration
Date: Tuesday, May 10, 2005
Time: 15:30, GMT Daylight Time, 16:30 CET

To attend this meeting, you must first register for it. Once you have registered for the meeting, you will receive an email message confirming your registration. This message will provide the information that you need to join the meeting.

The conference call information for the WebEX is on the registration page also.

To register for the DevPartner Fault Simulator WebEX, please click here

To register for the DevPartner SecurityChecker WebEX, please click here


DO YOU HAVE A COLLEAGUE who you feel would benefit from receiving this E-Zine?
If so, they can register to join the Compuware Insight Program by clicking here.

Copyright 2005. Compuware Ltd. All Rights Reserved.

This newsletter contains confidential information from Compuware Corporation. Use, disclosure or reproduction is prohibited without the prior express written permission of Compuware Ltd. Access is limited to authorised users.