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.
|