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.

Saturday, 23 July 2011

Google+ is a different approach

Many try to compare Facebook with Google+, and often they conclude that Facebook har more friends, so they will not switch to Google+.

However, Google+ should not be analyzed as a Facebook killer. It isn't. Facebook has a huge head start, and even though Google+ has grown extremely fast, most current users were already gmail users. For those that do not have Google accounts, Google+ is not as obvious.

It is not a good idea to compare two systems using a one-dimensional good/bad scale, there is much more to comparisons than that. Initially, Facebook really annoyed me, because each country in Europe had it's own network, and you could only be part of one network. Then, they removed that feature, and few people really noticed. Then they added groups, then they hid them well, then they added friend lists, then they added "Top news" and so on. The core of Facebook, that has persisted all the way, is a friend list and posts, and the ability to keep the profile 100% out of search engines.

Google+ has a different approach. The core seems to be the friend list and circles, but the friend list can include people that do not acknowledge the friendship. The profile contains part that cannot be hidden from the public, such as the name and photo. So, the list of friends works differently and the circles are part of the core user experience. By doing that, Google+ will be able to do other things than what Facebook can do, and generate a different user experience. It's like comparing a bird with a human - both have skills that the others have not, but some skills overlap.

There is no doubt that Google will integrate their services further. The Google+ account is used almost everywhere, from blogs to email, and circles are now supported by Picasaweb, Google Latitude, Huddle and Hangout, but will probably also come to Google Docs, and maybe we will see Google Groups reinvented as "Shared circles". So, instead of sending emails to the scout parents, you can now post on Google+, and some will receive the messages there, some will receive it by e-mail. Those that have Google+ accounts will be able to discuss the message online, immediately, without spamming people's mail boxes. And you can keep it totally separated from your Golf club while still handling messages from both in the same place.

So, what does Google+ kill? Well, currently, not much. But it will improve sharing of information, especially among people that already have Google accounts. But because the fundamental mechanisms are more advanced than on Facebook, more can be built on it. Facebook will continue to have the advantage of size for quite some time, which should technically put it in the position of being able to compete well, but because of Facebook's reputation, many may not perceive it as a serious way to share important stuff.

Will people have time for Google+? I believe that they will, because it can be a more efficient way of spending time, than looking into e-mails and various other online forums.