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.