Wednesday, 7 January 2015

Test-driven programming guidelines

We all know about test-driven development. How many actually do this? Well, medical device software is made this way. Maybe the tests are not automated, but developers are required to establish verifiable requirements before starting to write source code. Since you only know if a requirement is verifiable, if you know the verification method, that means that you must know a verification method, i.e. test, before you can start programming.

Let's go one level up: What about programming guidelines? For instance, if your company has introduced the OOD methods mentioned on this page by Dr Bob, how do you verify that they are actually used?

Let's take one example: Derived classes must be substitutable for their base classes. How do we verify that this works? Well, first we need to find all classes that have been derived from another class, and then we need to verify that this class works in a test that works with the base class. We can usually find all class-derivations by scanning the source code, so scanning the source code would be part of the verification method. Next, we get a list of class names, and base classes, and we then must verify, that these classes are substitutable. This can be fairly easy on TStringList inheritance, but how do you verify that TXyzClass works instead of TAnotherClass? It quickly becomes a lot of work.

So, seriously, what if there is one part of the code that violates these programming guidelines, will you care? If you don't care, but you still want to verify compliance on each software release, then you need to mark this class as approved non-compliant so that you can skip it next time, and it does not show up on your error-list on the next product release.

Most people will probably end up saying: We do not verify that we are in compliance with this principle, as that would be too much work. It is only meant to be a guideline or principle... and if they are still ambitious, they might make random checks to measure compliance, and/or make senior developers review code from younger developers before the final commit. But that means that you cannot tell outsiders, whether you conform to the principles, or not. Instead, you can only be sure that you are not conform to the principles. You can only say that you try to be as much as possible.

To outsiders, this is vague information about what is going on in a software development department, which usually reduces the quality of communication to other parts of the company. So, you may want to ask yourself this question: What rules does your source code actually follow? Can you prove it?

Tuesday, 26 February 2013

Turning the V-model upside down: The A-model

The V-model is well known in many software development models:

However, this drawing, which is very representative for V-model drawings, has several inconsistencies. One of them is the arrow, that goes back in time. Another one is, that it puts Operation and Maintenance into the Project Test and Integration side. I have seen many V-model drawings, and I never really felt comfortable with them. The reason is simple: The V-model drawings all assume a time axis, i.e. at the end of the project, you check if the software actually works... there is no iterative development, there is no sanity check in the middle of the software development etc.

If one assumes, that acceptance criteria and test/verification criteria are made before the software is developed, as it is known from test driven development and other methodologies, the time axis should be from top to bottom, instead of from left to right. Once you do that, the next thing is: Why is the model occupying most space at the top, and most work at the bottom? Let's turn it all around, and make the A-model:

Now we have appropriate sizing of the boxes, and the confusing time axis has been removed. Just like the V-model, it is possible to have different layers in the pyramid, and use different terminologies and methods.

So, where did the time axis go? That could look something like this:

  • Project is initiated, with user needs and validation criteria
  • Project is planned, with design input and verification methods and acceptance criteria.
  • Project is designed, which includes the creation of automated integration tests and unit tests. These may be done in parallel and iteratively, and it is possible to apply several design reviews, validations, tests etc. as part of this iterative process. The entire A-model's test-side will be applied, and the entire SPECs-side of the A-model may be changed as part of the iterative model.
  • Project has it's final test, which may include formal test plans and automated tests - but in some less critical cases, in order to shorten the time-to-market, it may not include all the manual tests that were done in the design phase.
  • Product is released.
Again, many different project models can be chosen, but the big work of writing the unit tests and integration tests, is done in parallel with designing and programming. Notably, integrations between software of different vendors is often integration-tested first, before details are programmed, in order to ensure that there is a connection between the two systems, early, so integration testing is started before unit testing.

I believe that this A-model represents most software development projects better than the V-model.

Monday, 26 December 2011

Process management for software development companies

Our bugtracker system has grown far beyond bugtracking, and that is the time where you need to realize, that bugtracking is not much different from managing a construction site, a catering company or many other kinds of businesses. It's all about automating the process, and this requires a generic process-automation tool, and not a bugtracker. So, why do people still get and install bugtracking software? I see several reasons:

1) The bugtracker screenshots shows data that end-users can relate to. If you see a screenshot with states, buttons and text that is similar to what you need, it feels comfortable. There are fewer things to check, than if the screenshot doesn't show anything that relates to what you want the software to do.

2) Integration with your existing tools. Things are much easier when things are integrated, right?

However, sometimes we need to make a choice, between what is right to do, and what is easy to do. If you can save 100 mandays by investing 10 mandays, it becomes a no-brainer. Well, if you can convince yourself, that the most tempting screenshot does not represent the right solution. It also requires that you know the alternatives, and most software developers never heard about process management tools like Joget or Bonita.

We have a list of possible tools to choose between, but we have not decided, yet. If you know good process management and production planning tools that make Bugzilla, Jira, Mantis, Team Foundation Server and Redmine look old, leave a comment.