Lifecycle Quality at Borland

Borland moves forward with Process.

By David Norfolk, 2nd November 2006

Borland is now promoting a new TLA LQM - Lifecycle Quality Management. This could be an interesting new focus for development teams, as long as people understand Quality in terms of "fitness for business purpose" instead of just "well, it meets corporate standards and there's some really neat code in there".

Lifecycle Quality implies that everyone involved with every stage of the product lifecycle is responsible for the fitness for purpose of the software they are building or supporting at all times – so "quality" isn't just something painted on by the QA people at the end of development.

Even so, you need more than just quality-aware developers. Someone must be accountable for quality, so there's still place for a QA team and a Quality Manager. But perhaps a better, more developer-aware, QA team, one which bridges the gap between users and developers. One which actively helps developers to build Quality in from the first rather than just saying NO! when they try to put their systems into production. At this point it is far too late - and expensive - to do much about poor quality, beyond fixing the cosmetics).

Nevertheless, quality-aware developers can at least deliver software that meets standards, addresses requirements, works and is reasonably understandable, ready for a final verification by QA, who can now concentrate on confirming that it is fit for business, while being reasonably confident that it will be.

LQM seems to be a key part of Borland's version of ALM (Application Lifecycle Management) now. It is one of its four "routes to value" - the central one, providing a sort of overall framework for the other routes to value: IT governance, change management, requirements management.

Requirements are a key aspect of LQM (requirements help define fitness for purpose) but LQM includes rather more than just requirements: requirements-based testing (that should fit well with eXtreme Programming), for example; and formal quality checkpoints on the way to delivery of a fit-for-purpose application.

In other words, when transforming Requirements into code, you can lose sight of what the application was all about - LQM is about addressing such issues when they occur, not about trying to mitigate the effects later as you’re going live. It's also about collaboration between all of the stakeholders in product development and - most important - operation; and about raising general awareness of quality issues.

For example, what are quality defects? They're not just functional bugs, as the development team probably sees it, but also unresolved security issues, usability issues, usage limitations, maintainability issues and inherent performance bottlenecks.

LQM is also about mentoring people,not just about tools (remember - People, Process, Technology). Many existing Borland tools are appropriate to LQM initiatives, although there will also be new tools - such as Gauntlet for proactive defect removal. We hope to bring you a first look at Gauntet, just as soon as our reviewer can check out the latest version, which suddenly has a revamped UI.

LQM is, fundamentally, about building quality into your process and, thus, about process improvement - implementing LQM will usually involve a phased approach and metrics, which confirm the success (or otherwise) of the initiative, so you can keep LQM on track. It doesn't appear to differ much from what Borland has always championed, especially since the acquisition of TeraQuest in 2005. But I think that Borland now has much more of an obviously holistic approach to quality.®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery

Send Corrections