Development: Don't let the software bugs bite

Feature

Development: Don't let the software bugs bite

teamtools150

Error-strewn programs can hamper IT's ability to enhance business efficiency. Cliff Saran explains how team tools, agile methods and automation can help IT departments provide what end-users really need

Software development is changing as businesses and public sector organisations look to speed up the introduction of products and services, with the applications supporting increasingly complex usages. To address this, development tools companies are offering team development tools.

Software development is seen by many as integral to IT's ability to support whatever the business wants. The challenge is that software development teams have neither the time nor the resources to build applications in an increasingly complex deployment environment.

Modern applications are expected to support not only in-house end-users but also mobile users who have limited connectivity, and customers and business partners via the internet. In some sectors, such as retail banking, an application has to work across multiple routes to market: whether a customer connects over a landline phone, the internet or a mobile phone or just walks into a branch, staff should be able to run the same application.

All this is happening at the same time that the industry is recommending that IT systems adopt a service oriented architecture - in other words, users should design individual applications so that the services they offer can be linked together to automate complex business processes. Needless to say, this is not easy.

Ovum analyst Bola Rotibi says, "Developers need to deal with the complexity of technology like intermittent wireless connectivity, web services and the internet." She says software development teams face an immense challenge in taking into account all these factors when building applications. Moreover, end-users' expectations of software have been steadily increasing, and poor-quality, buggy code or missing functionality is not acceptable.

Figures from the Software Engineering Institute at Carnegie Mellon University estimate that every 1,000 lines of programming code contains between 100 and 150 errors. That means up to 15% of code contains bugs.

The software tools industry is now targeting this problem. "IBM, Microsoft and Borland have realised that they need to raise the credibility of the people building the applications," Rotibi says.

Team development tools are designed to address common issues around miscommunication that organisations encounter when teams of programmers work on the same application. Team tools enforce programming standards, and allow people with different sets of skills to collaborate on a project.

There has been a shift in the way software developers need think and work as organisations look at ways to make programming more productive. Software project teams are increasingly realising the benefit of including end-users from the business on the project team. Putting end-users alongside programmers can help reduce the misunderstandings that result in projects failing to meet expectations. The earlier a shortcoming in functionality can be identified, the cheaper it can be rectified.

This is one of the principles of agile development, one of the new approaches to developing software. Agile programming is an iterative process: software is developed continuously with constant end-user feedback. With the traditional, procedural, or waterfall, approach, end-users are involved during user acceptance testing, by which time it can be costly to make fundamental changes to functionality of the application under development. This is one very good reason for getting end-users involved in the development process as early as possible.

Agile programming requires a different mindset to traditional programming. Matt Hotle, vice-president of research at Gartner says, "We are seeing teams made up of end-users and developers working on the same projects." The benefit, he says, is that the end-users are always available, but the challenge for IT directors is to recruit end-users prepared to get involved in a software project.

Even after gaining end-user support on a project, IT directors have to win over programmers, who are not accustomed to the constant involvement of end-users in a project. Programmers may also be suspicious of other aspects of agile programming, since it relies on programmers inspecting each other's code. "Most organisations have programmers who do not like their code inspected," says Hotle.

Key to the success of agile programming is testing code early in the development process. In fact, Hotle suggests that users should approach agile programming by emphasising testing. "Build a test plan, then build the code," he says. Again, this requires a change to the way software teams normally run projects.

IT directors need to adapt the programming approach they take, depending on business needs. Hotle urges users not to stick rigidly to a programming model like agile development if they operate in a heavily regulated sector, since the agile approach does not require documentation. "You have to be prepared to deviate from the methodology," he says.

Given that applications are harder than ever to develop, why rely on error-prone coding at all? An approach called model-driven architecture (MDA) can reduce the amount of code that programmers need to write.

MDA is designed to make it easier to specify the requirements of a program being developed by using UML (Universal Markup language). UML provides a visual model, allowing a software development team to gain a better understanding of what the application is supposed to do. Using this model, MDA can automatically generate code for the application, which can save a significant amount of software development time and bring down the error rate considerably.

Analyst firm Butler Group estimates that MDA can reduce coding errors to 3.2 errors per 1,000 lines of code. Although it is unlikely that an entire application would be developed using MDA to generate the code, Butler Group analyst Michael Azoff says a lot of an application's infrastructure and plumbing could be generated automatically.

The core component in team development tools is a source code control system, which stores every line of code written and keeps an audit trail of changes to the code and who made each change. A source code file would normally have to be "checked out" by a developer wishing to make changes to the code, and the amended code checked back into the source control system.

Along with the source code control system, a technique known as static code analysis can check that the code conforms to house style. This is achieved either through a manual process known as peer review - where members of the team assess each other's code - or by running a static code analyser on the source code file. The analyser contains a set of prebuilt rules and highlights any deviations.

But Azoff warns, "Without changing the culture in the team, these tools will have an adverse effect." In his experience, team members may choose to work around the restrictions set by the team development environment to ensure compliance with coding standards or simply not use the software development tools at all.

Progress is being made to assess the level of compliance with coding standards. For instance, tools company Enerjy has developed a reporting tool to identify when individual programmers are not adhering to company standards. The Java-based tool aggregates reports from testing and source code control systems that project managers can consult to track whether programmers are consistently ignoring coding standards.

 

Case study: DaimlerChrysler drives up quality

DaimlerChrysler's subsidiary DaimlerChrysler Technologies, Services, Solutions (DC TSS) provides e-business services within DaimlerChrysler for strategic and critical web applications based on either J2EE or .net technology.

The programming team at DC TSS has been using static code analysis to ensure code conforms to a set of defined standards set by DC TSS.

Static analysis is a technique where a developer's code is checked automatically based on a set of rules to determine if the code conforms to "house style."

The information produced by the static code analysis tool is used for quality control during code review - where the software the developer writes is checked.

Maxim Chpakov, senior software engineer, said, "If you don't respect coding patterns, you risk getting barely maintainable code."

The quality control team of DC TSS has used a Java code analysis tool from Enerjy to increase the quality and speed of code reviews while reducing costs. "The benefit of software quality is that it saves money in the maintenance stage of a project," Chpakov said.

The team also found that using Enerjy in the early stages of development helped to prevent errors in code. "We are using Enerjy during our code reviews, running it over code to find the places where mistakes were made and coding patterns that were not used."

Enerjy contains 244 predefined rules and lets users add more rules, allowing the DC TSS quality control team to increase the depth of their code reviews and improve the quality for their customers.

 

Case study: Matra tightens its processes

Matra Systems, an independent software company specialising in retail, is an early adopter of Visual Studio Team System, joining the programme a year and a half ago.

Martin Crimes, chief technology officer at Matra, chose the tool to improve the efficiency of his software team. "When you split software development across the world, you need to get processes right," he says.

In preparation for a project due in December, Crimes switched development from an approach based on Prince/Prince 2 and rapid application development to an agile methodology called future-driven development, supported through Visual Studio Team System.

Crimes made the change to tighten Matra's documented processes for software development.

"We found some processes were not defined in our documentation," he says. This was because project managers had tweaked the coding specification set by the company to make it work more effectively in real projects. But Crimes found that in some instances developers were unsure of what processes to follow, since the changes had not been documented.

With Visual Studio Team System, Crimes has been able to implement a structured approach to software development. The built-in source code control system uses rules to ensure code written by developers conforms to company standards. If a source code file written by a developer does not comply with the rules, it cannot be checked into the source code control system it and an error is produced.

"You learn very quickly if you try to check in a file three times and it fails," says Crimes. Basically, each developer has to ensure their code is compliant before they can check it back into the system.

Preparation to moving to a more controlled team development environment began with a training session on future-driven development for two project teams, followed by a test.

"We tried a dry run to see how Visual Studio Team System would run," Crimes says. He followed this up with a real project, a small bespoke application, to determine how the system could best be used to improve processes in software development and where it did not fit.

Crimes plans to use Visual Studio Team System with the future-driven development approach across all software development at Matra during 2006.

 


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in November 2005

 

COMMENTS powered by Disqus  //  Commenting policy