Why software quality matters
clarification Bad software can cost a company millions of dollars.
That is why project managers should strive for high-quality software, and not only to be on time and within budget.
Ng Koh Wee, the regional application head for Great Eastern Life Assurance's IT group, told ZDNet Asia in an interview that the lack of quality software "will manifest in the business ultimately".
"Every time an error was discovered in production, where we processed insurance policies and sent documents or letters to clients, it resulted in almost a seven-digit loss," Koh said, recounting past experiences.
In one case of delivering bad software that occurred a few years ago, Koh said, the company ended up overpaying OCBC Bank, its bancassurance distribution channel, by S$6 million (US$3.7 million). "We were able to recover the loss, but imagine if we couldn't," he noted.
Although not all defects result in hefty financial losses, and there are instances where it is just a matter of "restoring the data and re-running the job after we correct the error", Koh believes there is no substitute for good quality assurance (QA) practices.
"We started this concept at Great Eastern about four years ago. Before 2000, we didn't have a quality assurance team. So it was only after 2000 that we started having larger scale projects and placed emphasis on quality assurance," he said.
According to Ng, the objective of QA is to discover a defect at the earliest stage of the software development lifecycle.
"When it comes to software defects, if it is discovered later in the development cycle, it will be more costly to rework it. Anyone who runs projects knows this," he said. "But if you discover the defect at the requirements study stage, it's just a matter of re-documenting the requirements."
The insurance company has a dedicated QA manager for larger scale projects such as the replacement of its core system, but in smaller projects like developing the company Web site, the project manager typically doubles up as the QA manager.
Ng explained: "That (core system replacement) project has a QA team comprising various people who, at various stages of the project, will dive in and make sure certain processes that were agreed with the project team have been executed [according to plan]." Doing so "is necessary to verify that the proper processes [are in place] and quality is ensured in the project at every stage", he added.
Challenges of development
Industry experts say that the challenges are manifold for IT departments which strive to deliver applications on time, within budget and according to the business objectives.
As Julian Quinn, Borland's vice president of Asia-Pacific, pointed out, there is "better technology available now than ever before, yet there is a high failure rate" in IT projects.
Quinn said the traditional "sequential process" of software engineering--which starts with scoping out the requirements, moves to design and modeling, and ends at testing--lends itself to several problems.
"You have very different sets of expertise in each area, and the developers in one area don't know what's happening in another," he noted. "So it's like a disconnected supply chain, and if you consider the time compression as a key issue where everyone wants to produce much faster today than ever before, this is not a scalable model."
Quinn added that there is a huge opportunity for misinterpretation to occur throughout the lifecycle. "If you make errors at, say, the requirements phase, and you incorrectly specify the requirements, by the time you actually develop it and pick up the errors at production, the costs and issues would have compounded," he explained.
The lack of transparency, visibility and integration across the development lifecycle adds to the complexity of the software engineering process.
"First, you have people in different roles with specific areas of expertise, who don't necessarily have the visibility, the transparency or a clear understanding of the requirements, whether it is at the design phase or any of the phases of the lifecycle," Quinn said, noting the problems compounded by the limited communication between the different groups.
Mike New, managing director for ASEAN at Mercury, a provider of application testing and management tools, agreed there is a need to improve communication and collaboration.
"Quality plays an enormous role, and there is the need to break down the proverbial wall between development and operations, and allow the entire lifecycle to be expanded and examined from many perspectives," he noted. Typical silos are between the line of business and the IT organization, as well as between development, quality assurance and IT operations.
"The basic philosophy of communication goes quite a long way in solving many of the problems created by silos of traditional development and operations," New added.
Cross-functional team meetings with representatives from business, development, quality assurance, and operations, are critical in assisting each side of the proverbial wall in understanding the issues faced throughout the course of a project, he noted.
"More understanding equates to better management of any issues that arise throughout the project. To completely satisfy the customer and deliver on service level agreements, silos cannot exist," New said. "To truly focus on the entire application lifecycle in a parallel fashion, silos must be shattered."
Another contributing factor to software complexity is use of varied technologies, which could cause problems regardless of the size of the project, noted Borland's Quinn.
He also highlighted the difference between "building the software right" and "building the right application". "You can do the software right by automating some of the tools but it doesn't necessary infer that you're actually building the right application in the first place…you truly need to look at the value of the software," he said.
QA has gained heightened awareness in recent years, but it demands greater consideration from businesses, especially those which opt for offshore development, noted Quinn.
"The development process is exacerbated by offshoring, since the offshore partner may have different sets of processes for development," he explained.
According to Quinn, distributed development, which invariably takes place over different time zones, lends itself to communication issues, cultural issues, version control, change management, and not to mention the issues resulting from different processes and methodologies.
"Companies are offshoring because they it is cheaper, but they need to make sure they've got the processes in place so that they can manage the offshore service company and the final product," he said. "You may choose to offshore to companies in India or China which are good in development, but if you haven't defined the requirements and processes effectively at the beginning, you'll still have the same problems."