Software development - a lot more than programming: Part 2

In the same manner as it is important to keep track of code changes over time, development teams ought to keep track on all feature requests, bug reports (both new and fixed) and to-do items as well.

These issues are typically stored in a centralised issue management system (often called a bug database) on the server. Several bug database systems are available free, such as Bugzilla and Trac. Other popular bug database systems include Mantis and JIRA.

A modern C/C++ development tool should be able to connect to a bug database server and provide integrated features for listing, searching and editing of bug reports and feature requests right from inside the C/C++ environment.

Some tools go even further and integrate both code editing and debugging towards the bug database system.

Atollic TrueSTUDIO, for example, remembers which files were opened the last time work was done to a specific bug report, and if the bug report is activated (maybe weeks) later, the editor will automatically open the same C/C++ files that were opened the last time work was done on that bug.

Other features integrated into the product are possibilities to document the state of the debugger using screenshots, which can be added as a file attachment to a bug report. The screenshots from the debugger can be cropped and annotated with arrows and text, from inside the tool.

The next time someone opens the bug report, the screenshot from the debug session is available as additional information related to the bug report.

Finding errors using a debugger is often necessary, but to fix a bug, it must first be detected. It is far cheaper to find the bug before the test phase is started, not to mention before the product is delivered to customers.

Development teams should thus strive to find and correct bugs as early as possible in the development cycle.

Companies who develop software for safety critical systems (such as the aerospace industry) have become good at finding software errors even before the product goes into the test phase. This is achieved using a stringent requirements definition and code reviews where developers study each other’s code and thus identify potential problems.

Code reviews are considered by many to be one of the cheapest and best ways to improve software quality, but surprisingly enough there has been virtually no tool support for this until now in the embedded industry.

Modern C/C++ development environments ought to integrate code review functions, in the way that has already been done in Atollic TrueSTUDIO. Using this tool, a project manager or a team member can create a code review session by defining what files in the project shall take part, and what team members shall become reviewers.

Reviewers can then study the source code files in the editor using their own computer, and add code review comments to various source code lines using a couple of mouse-clicks in the editor. Review comments are classified by the reviewer (such as logic error, portability problem, maintainability, etc) as well as priority (such as critical, major, minor etc).

In the second phase of the review, all reviewers sit down and discuss all the different review comments together in a code review meeting and optionally assign them to different team members for fixing.

Using this simple methodology, software quality can be improved. Reviewers can study the code in their own time and all team members taking part in the review meeting improve their coding skills by learning from the colleagues and their mistakes.

Now that functions for code reviews are getting integrated into professional C/C++ environments, there is no longer any excuse not to use this methodology, at least for the most critical parts of the application.

The last part of this three-part series will be published soon.