International Developer Logo Last Updated 24.07.08 at 11.48
On Sale
This months front cover, click to see the table of contents.
Subscribe
Powered by SEEK
Keywords (optional)
 
FEATURES

Quality: The Missing Link in Software Development


Andy Seager, Director of Solutions Marketing, Borland EMEA   11.02.08

 

Title:  Quality: The Missing Link in Software Development

 

By Andy Seager, Director of Solutions Marketing, Borland EMEA

 

I find it incredible that in this day and age software development continues to be more art than science. It is 2007; with all the knowledge, resources and technology available to us today, why are companies still struggling to consistently deliver high-quality software?

Project cancellations and failures have become ubiquitous and cost overruns, schedule slippages, low quality and poor reliability disturbing norms in the software industry.

 

Technology companies have been hard at work developing tools and solutions designed to improve software application development processes and software quality – although the results may not always reflect this. Software development organisations have been and will continue to be under increased pressure to adopt more mature, comprehensive and proactive approaches to ensuring software quality. While traditional approaches to achieving quality relegate most software test and validation to late in the application lifecycle, many IT organisations are now placing an increased emphasis on testing more effectively and more frequently throughout the software delivery lifecycle.

Certainly vendors offering automated software testing products have made strides in this area; however, the fact remains that IT organisations still have no level of visibility or control over what is actually happening during the development process.

 

Many project teams still operate as individual “silos” that utilise their own approach to quality. This results in disconnected practices that foster inconsistencies throughout the development process. Even worse, many development teams still rely on largely manual and homegrown approaches that add to the cost and complexity of quality practices. This leads to the loss of quality-related information, duplication of efforts, poor testing coverage of critical functionality, limited visibility into overall application quality, and ultimately, unpredictable quality across projects. Companies need to strive to adopt standard processes for defining, measuring, managing and improving software quality that begin at the beginning of software projects, not depend on what happens at the end.

 

Instead of relying on guesswork and anecdotal evidence, companies are now beginning to implement more efficient and effective software development processes based on metrics and objective measurements. What's more, today we see that more companies are beginning to hold developers accountable for software quality. Many companies are distributing quality responsibility across the development lifecycle by providing the means for developers to address quality within their established processes and ultimately focus their energies on "getting software right" from the start.

 

In order to deliver quality software, organisations should adopt an approach that infuses quality throughout the entire software development lifecycle. Such an approach should encompass four core quality processes—planning, validation, improvement and management:

 

Planning (Define and Prioritize)

·         Analyse and classify requirements: Requirements should be delivered and prioritised according to business needs.  This prioritisation must then trace all the way to the most finite unit or object-level activities to assure teams are united in their goals.

·         Perform risk analysis and prioritise quality activities: Risk is inherent in any software development project; those who analyse the risk to develop their project and quality plans have the potential to minimise its impact.

·         Define and build quality plan: Without a map, it is hard to successfully navigate new areas. Organisations need to define application quality goals that meet the application business needs.

 

Validation

·         Process audits: Defined processes enable teams to function efficiently and effectively, allowing them to see what is required of them in their project role and help software development teams follow the selected processes and procedures. Consistent reviews of process lead to consistent improvements in efficiency.

·         Peer reviews: Two heads are better than one when it comes to addressing most challenges. The same is true when it comes to ensuring software quality. Best practices for software quality include peer reviews of all types of work products (requirements, design, code, tests) to ensure they conform to customer requirements and organisation standards.

·         Work product analysis: If quality requirements are not defined early, major architecture errors can be made, particularly when it comes to performance expectations. Aspects of the architecture should be examined and design choices made before much of the system coding begins. This type of early analysis provides the assurance that a design can confidently be committed to code and that quality requirement can be met.

·         Create and execute test cases and suites: Creating appropriate, prioritised and efficient tests is the “art” of QA professionals.  Harnessing the process of testing is often the difficult and mundane aspect.  So, effectively managing the creation, management and execution of all manner of testing becomes the challenge of all organisations.  However, this is where repeatability, visibility and economies of scale really enable consistent results from project to project.

 

Improvement

·         Analyse results of process audits, reviews and tests: With every release, organisations must improve the quality of their software projects by analysing the results of validation activities and comparing them with their expected outcomes as defined in the planning activities. It isn’t just about analysis of technology issues.  Analysing the process itself leads to continuous efficiency gains.

·         Diagnose and pinpoint issues: In the short-term, analysis of defects to determine their root causes may be perceived as time-consuming and costly, but it can save significant resources in the long run.  Finding issues should be the preliminary goal of testing; fixing the problems completes the process.

·         Update work products and re-verify:  The final phase of the improvement process area is validating that improvements actually achieve their goals.  The requirements, design, code or test need to be repaired, and then reviewed or tested again, to ensure that the repair correctly handled the defect.

 

Management

·         Status tracking and reporting: Managers must have the necessary lifecycle quality information on hand at each stage of the software development lifecycle to make the right decisions. Organisations must be able to obtain real-time reports on quality status and project progress to enable efficient resource management and further understand release readiness.

·         Control all phases of quality management from start to finish: As software travels through the delivery lifecycle, companies need support for all of their quality processes, yet software development organisations have limited time and resources. To minimise costs and time to market, all resources need to be managed efficiently. Control systems enable businesses to effectively manage activities and assets that drive quality results.

 

The Future of Software Delivery

We are starting to see the shape of a very different future for software development – not only how it is created, managed and delivered, but how it is able to connect all stakeholders in an effort to improve quality and performance. The approaches outlined above enable teams to consistently deliver high quality applications and services that meet business requirements, while systematically reducing costs, risk, defects, rework and time-to-market.

 

It’s time to deliver quality software consistently – be it service-enabling legacy applications, developing new applications or customising packaged applications. It needs to become a managed business process, based on metrics and objective measurements, rather than guess work and anecdotal evidence. Finally, there needs to be an established process, supported and automated with the right tools, inspiring confidence that the output is going to be reliable, predictable and of high quality.

 

 

 





HAVE YOUR SAY
This article is rated  Rate this article 
 
Editors Letter
Picture of the Editor  
Alphabet Street 

Each month we try our hardest to cover every angle and aspect of software engineering. Indeed, we pride ourselves on our platform-agnostic wide ranging view of the development landscape. How then could we push ourselves even further and really broaden the spectrum of our editorial coverage? The answer had to be – the complete A to Z of software. Well, not complete, but a rip roaring twenty-six letter technology tour to provoke some interest and thoughts in areas you might not normally think about.

But first, a personal confession so that you know how all this started. I actually got the idea from reading a cookery magazine that had done something similar. You know the kind of thing – A for apples, B for bread, C for custard and so on. But those pesky food journalists have it easy don’t they? When they get to X, Y and Z they can just use X for Xérès Sherry, Y for Yeast and even Z for Zabaglione.

Now, X is simple enough with plenty of XMLs out there, Z for zero tolerance we reckoned, but Y, wow - now that is a hard one.

So, please dive in and jump to your favourite letter. It was always going to be the case that we would miss out on a few key areas, but we think it’s pretty cool to be able to work your way through the whole alphabet and just stay within the world of software development. Next month, 1001 aspects of application development and how you can implement them in your daily working schedule. Joke – ok?

Happy coding!

Adrian Bridgwater

Editor

Write to the Editor