Software development - a lot more than programming: Part 1

As microprocessors get increasingly more powerful, so does the appetite for additional software functionalities. Size of embedded systems software increases every year, bringing new types of problems.

The software industry agrees that the largest problems while developing software are no longer how to write the individual code lines; today’s problems are more related to managing ever-increasing code complexity, increasing development costs and delays, geographically separated project teams, and too low quality in many software products.

Still, it is surprising to see that almost all integrated development environments for developing embedded systems software focus on the same tasks as 20 years ago, mostly the traditional chain of editing, compiling and debugging code lines only.

With better development tools, covering a wider field of problems facing software developers in their everyday work, development times can be reduced and software quality can be improved.

It is also important that developers move from considering themselves as ‘programmers’, and understand that a professional embedded developer of today needs to be a ‘software engineer’ as well; ie, he or she needs to understand and practise the process of how to develop software well, not only write the actual code lines.

Admittedly, tools have been improved over the past 20 years, but it is still primarily the traditional steps of editing, compiling and debugging that are handled. Editors are, of course, better today; developers expect features like expand/collapse of code blocks, spell checking of text in C/C++ comments, functions for visualisation and navigation of the code structure, etc.

Today, embedded compilers handle C++ as well as C and code size is improved even if that is less important in the new powerful 32-bit devices. The difference in size between compilers from different vendors is marginal in most cases, and the free GNU compiler is in many cases even better than commercial compilers.

Debuggers are better too, but it is still functions for execution of code and inspection of variable values that are in focus.

By looking at tool support in a wider perspective, development teams can start to address the problems that really cost money, delay projects and cause companies to deliver software products of low quality. These problems are attached with a real cost, either in terms of money, calendar time or in damaged company reputation.

Modern C/C++ tools ought to extend the traditional features (editing, compiling and debugging) with new features covering support for design and documentation, team collaboration, traceability in code changes and better tools for improving software quality.

One way of improving the work methodology is to better describe what should be developed before coding starts. This can be done with UML (the unified modelling language), a standardised graphical language for visualisation of software using a number of different types of diagrams.

Examples of diagram types are class, activity, sequence, and state-chart. Atollic TrueSTUDIO is an example of a C/C++ tool that integrates graphical UML editors right into the C/C++ environment to give developers better possibilities for requirements capture, and to model the static structure as well as dynamic behaviour of the application.

UML tools for embedded systems have traditionally been expensive and often required a change of work methodology at the entire development department.

A much cheaper and softer way info graphical UML modelling is to choose a C/C++ environment with UML editors built in right from the start.

Most seasoned development engineers have experienced changed requirements, the code needs to be extended and modified, experienced developers leave the project and after some time, no one knows how the code works or why.

Furthermore, no one remembers when a certain change was made, why it was made or what the code looked like before the change.

A good solution that all companies ought to use is a version control system, essentially a database containing all files in the project, including all older versions of them from the project start. A good version control system will not only store all earlier versions of a file, but also old versions of the complete directory structure in the project.

A version control system gives full traceability, and it is easy to work out which program line was added by whom, when and why. It is also easy to revert to earlier versions and to create parallel code bases that can later be merged again.

Releases can be labelled so it is easy to restore the source code for a specific earlier release. A common function is to make a graphical ‘file-diff’ that visualises graphically which lines have been added or removed then comparing two versions (in time) of the same file.

A version control system is a must if several engineers work simultaneously in the project, especially if they are in different geographical locations. With a version control system, several developers can work in the same source code file simultaneously, and ‘check in’ their changes independently from each other.

Other developers can synchronise their local work copies with the latest changes from the server at select times. All developers thus have access to the latest changes in a file, independently of who made the change.

Version control systems are often classified as team collaboration tools and it is true that they are very useful (in fact, almost a must) in projects with several developers. But a version control system is equally useful in smaller projects with only one single developer, as it gives full traceability and it becomes easy to find earlier versions of the code and to track changes over time.

Atollic TrueSTUDIO, for example, even auto-generates graphical charts that visualise the code activities (such as commits, branches/merges and labels/tags) that have been recorded in the version control system server during the project’s lifetime.

Many popular version control systems are available on the market, both commercial and opensource. One of the most popular ones has been the now ageing CVS, which largely has been replaced by the newer Subversion.

Subversion is open-source and thus free of charge, is successfully used by many companies worldwide, and can be deployed on a team server or on a single developer’s computer.

A modern C/C++ IDE ought to have deep integration to popular version control systems.

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