Paying attention to software processes to achieve higher quality code -

Paying attention to software processes to achieve higher quality code


Software development is inherently difficult, expensive and errorprone. Additional constraints are imposed when developing software forembedded systems, such as reductions in available memory, processorspeeds and I/O devices, as well as influencing factors of the operatingsystem, real time requirements and complex communication protocols.Therefore, it is vital that the right approach is used as the softwareis developed.

In order to assist the software developer, great minds of the 20thCentury collaborated to discuss and implement the Waterfall model, andit's mutated cousin, the V-Model. These models are still widely used inindustry today, especially in the defence industry.

The problem is that you cannot 'use' the V-Model to create software,anymore that you can 'use' an Airfix model to fly to Paris. In orderfor the V-Model to be 'used', it needs to be backed up with astructured software development process, which explicitly defines theoutputs of each stage and how those outputs are produced.

The V-model of software development
Figure 1 below shows a typicaldiagram of the V-Model. The development life cycle follows a fixed pathfrom Requirements Analysis to Operational Testing and subsequentdelivery to the customer. Testing tasks are generated from knowledgegained from development tasks, for instance, the High Level Design willgenerate the Integration Tests. A project following this model willmove through these tasks one at a time, moving on when the current taskis completed.

This model does have a number of good points such as:

It defines tangible phases of the process, and proposes a logicalsequence in which these phases should be approached.

It defines logical relationships between the phases.

It demands that testing documentation is written as soon aspossible, for example, the integration tests are written when the highlevel design is finished, the unit tests are written when the detailedspecifications are finished.

It gives equal weight to development and testing.

It provides a simple and easy to follow map of the softwaredevelopment process.

However, there are a number of criticisms that have been levelled atthe V-Model:

It is easily misinterpreted as a working model, whereas it needsto be backed up with a good software development process.

It is rigid in its approach ” it has no iteration, and it doesn'thandle change

It is rigid in its testing methodology.

Figure1: The V-model stands for victory in achieving software quality

The most damaging aspect of the V-Model is not in the model itself.Any model is an approximation, and this model does at least providesome value. The biggest problem arises from the users' steadfastreliance on the model, making the assumption that the model is a 'tool'to be 'used'. The V-Model cannot be 'used'. Only a good softwaredevelopment process can be used to create good software.

In addition, the user can further distort the picture by thinkingthat iteration can be added by cobbling together multiple V-Models toform some sort of 'WWWWW' model. This is nonsense without an iterativeprocess to back it up and with such a process it is no longer aV-Model.

The third criticism levelled at the V-Model is in the testing phasesand has been illustrated by Brian Marick. He explains that implementingunit tests and integration tests as single, separate phases results ina thoughtless approach to testing. For example, a single unit test willrequire a custom test harness.

Each unit may require a different test harness. For large projectswith lots of units, this could prove to be costly and problematic. Itcould be a better idea to test a unit when connected to the actualsystem, using the system to deliver test messages. The point is that nothought is being applied to the trade-offs involved in testing early,testing late, or testing as-you-go.

All is not lost! There are many cases where the V-Model and theWaterfall model have been successfully used. In these cases, therequirements were correct before any development work was started (thisrequires more work up-front to make sure the requirements are accurateand unambiguous), and a software development process was used, inconjunction with the model.

In other words, a clear process was used to define and enforce theboundaries of the different phases of the model. One example of this isthe (now outdated) US DOD standard MIL-STD-498 (and its predecessorDOD-STD-2167A), which requires review documents such as SoftwareRequirements Specifications and Software Test Plans to be producedafter every development phase (Figure2 below ).

Figure2: MIL-STD-498 software development process.

(To see a bigger version of thisdiagram clickhere. )

So, the message here is that with the proper procedures and fixedand clear requirements, you could use the V-Model. However, there areother, newer processes that are better at handling changingrequirements.

Accommodating change
Let us take a look at the software development process for a moment. Asstated by P.G. Armour, in 'The Laws of the Software Process', softwaredevelopment can be viewed as a quest for knowledge. Like a climberplanning a route over glaciers and up a mountain face, the destinationis clear, but getting a safe route up the mountain and back down againis not easy.

The climbers may find impassable chasms, dangerous overhangs orunpredictable changes in weather. When planning as ascent, the climberis faced with two options: Invest in high resolution cameras, satelliteimages, remote camera drones and sophisticated weather predictionmainframes to gain knowledge and spend years planning the safest routebefore setting foot on the mountain, or plan as much as you can withthe resources you have and then attempt the climb, knowing that theplan will most probably change as you go along.

The software manager is facing the same two choices, except that nowthey boil down into: determine all your requirements accurately andunambiguously, and research the software system to be developed inorder to gain a complete understanding of the problem space, before youdo anything else, or start your project with the understanding that notenough knowledge has been acquired about the software systems to bedelivered, and that the requirements and the software development planwill most probably change.

These two choices can be further distilled down: use a rigid model,like the V-Model (backed up with a solid process and lots of upfrontresearch), or use an Agile software development process

The problem here is that if you follow option 1, you will never havea complete picture of the software system until it is delivered to asatisfied customer.

There will always be a risk that some vital piece of knowledge inthe problem domain has yet to be uncovered. The customer(s) may noteven know what is required from the software.

More upfront research can reduce this risk but never eliminate it.Is it not better to accept that the plan will change and to accommodatethis in your software development process? Isn't it time you started tolook at Agile Software Development?

There are many different processes that can fall under the label ofAgile Software Development, such as Extreme Programming (XP), Crystal,DSDM and Scrum. There are also many big guns in the software world thatuse Agile methods, such as Google, IBM, HP, Microsoft, Sun Microsystemsand Yahoo. And yet, agile software development is often misunderstood.

It does not involve a bunch of hackers getting together and startinga coding frenzy! It is a well established (although not yet widelyadopted) software methodology that emphasises frequent and rapiditerations through a software development process to deliver highlyfunctional software that meets the customer's changing requirements. Itencapsulates a number of related software development concepts, a smallsubset of which we will describe here, to give you a flavour of theAgile Software Development process.

Test driven development
In test driven development, you write your test code before you writeyour production code. Then, the production code is written which shouldmatch the test case in the new test code, making the failing test pass.

The amount of test code and production code should be small, say 5lines of code each. Once the test passes, then the cycle repeats andthe test code should be enhanced to develop a new test case, followedby more matching production code. In this way, the software will alwayshave matching test cases, which are constantly executed, ensuring thebehaviour of the system has been thoroughly exercised.

Continuous Integration
Once the code builds and passes its tests, you grab the integrationtoken (which is a physical object to ensure only one integrationhappens at any one time), check in your code and then use a separatededicated integration workstation to get the changes, run the build andexecute all the tests. If it works, then the integration was a success,and the rest of the team can get the changes and work with them. If itdidn't work, then the problem needs to be fixed. Go back to yourworkstation and find out why the build is broken.

Continuous Integration means that integration problems are found andresolved frequently, so that the code is always ready to ship, even ifall the required functionality has not yet been developed.

Pair programming
The idea of having a colleague looking over your shoulder pointing outsyntax errors fills many computer programmers with dread and rightlyso. Fortunately, pair programming is far from this. It is in fact anextremely powerful and productive way to work. In essence, one personwill code; the driver, the other person will navigate ” staying onestep ahead of the coder and thinking about the next tests that arerequired to develop the next piece of production code.

These two will swap roles frequently and pairs will pair up withdifferent members of the team throughout the working week. This levelof interaction can greatly increase the amount of brain power appliedto the software development process.

Unfortunately, the Waterfall and V-Models are not process models,they are abstract models and the models do not define the process to beused to create software. Thus, they are open to misuse andmisinterpretation and can lead managers into a false sense of security,as they rely on the model when they should be relying on a process.

Even with a good process, the V-Model has no iteration, and does nothandle change. If the risk of change is low, then you can get away withthis, but in any project where the risk of change is high, then it isbest to look at Agile Software Development processes in order toembrace change.

Ed Liversidge is with Harmonic Software Systems.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.