Chris Birmele's Blog : Software Engineering

Want to know the magic formula of how to develop software successfully?

ChrisBirmele — Wed, 25 Mar 2009 03:12:00 GMT

The magic formula is: Success == People + Process + Tools

Well this is hardly a revelation of historic proportions, but why is it people keep looking for that elusive tool that will solve all their problems? Tools are very important, don't get me wrong, but they are not a substitute for inappropriate processes and they are certainly not a substitute for lack of skills - they are a necessary complement.

So which addend carries more weight? Well it depends .... :-)

If we view software engineering as a series of transformations (shown below and explained in detail here) starting with a business need and ending with a software solution - tools become more useful the closer you get to the source code.

At higher levels of abstractions (i.e. during analysis or design) processes and people are very important and when gathering requirements people are by far the most important addend - why do you think poor requirements continue to be THE major challenge in software engineering?

NOTE: I am not suggesting these activities occur sequentially or result in producing formal artifacts.

Requirements Management with VSTS?

ChrisBirmele — Thu, 08 Nov 2007 08:56:00 GMT

So you think we can't do this in VSTS? Steve Lange has written an elaborate 4-part series about how you can(with and without partner add-ons). Check it out here.

Requirements? What exactly do you mean?

ChrisBirmele — Wed, 31 Oct 2007 08:16:00 GMT

Have you ever wondered why specifying requirements continues to be a major challenge for most organisations? Well there are many legitimate reasons, but using the term "Requirement" in the first place isn't helping ....

Read this paper if you want to fix this.

Lost in translation - or the Bulls Eye framework

ChrisBirmele — Wed, 17 Oct 2007 09:40:00 GMT

A software development effort is essentially a "translation" of a business need into a software solution. The problem is that several "translations" are required before machines can take over and generate the final software product.

The process typically starts with some requirements gathering, perhaps some level of analysis and design until code can be produced. Each of these steps represents a layer of abstraction that is essentially an interpretation of the previous layer .... In a perfect world, all these translations are perfectly aligned and a given business needs translates into a perfect solution - the center of the bulls-eye!

Now here is the challenge...

For each of these abstractions we use a different technique, i.e. natural languages for requirements, graphical notations for analysis & design and programming languages for the actual source code. Each of these techniques has very different characteristics with respect to semantic richness and precision. Natural languages are semantically extremely rich but very low in precision, programming languages are exactly the opposite, semantically very poor but so precise that a compiler can interpret it.

There have been many attempts to find a solution to this inherent problem, model-driven development is one them. Agile development ignores the translations in the middle focusing instead on churning out code until it meets business needs more or less. Bertrand Meyer tried to solve this problem by creating a single notation that can be used to capture requirements, source code and everything else in between (the notation is called "Eiffel").

The world is still looking for a solution..... Whoever is going to solve this fundamental problem is going to make a ton of money - and probably wins the Nobel price!

ALM versus SDLC - two different things

ChrisBirmele — Mon, 23 Apr 2007 01:38:00 GMT

You may hear that "VSTS is an ALM tool" when talking with a Microsoft rep or techie. This is not a misrepresentation but what they often mean is that "VSTS is an SDLC tool". Unfortunately marketing got their hands on this acronym and IMHO got it all tangled up. Lets deconfuse the two very distinct things:

SDLC == Software Development Life Cycle; this includes everything to do with DEVELOPING a software application, including requirements, architecture, coding, testing, configuration management project management

ALM == Application Life Cycle Management; as the name suggests includes everything that is part of the Application Lifecycle. When does the life of an apps start? No, not in development, it starts somewhere in the business as an idea, a need, a challenge, a risk. When does the life of an application end? No, not at the end of development, but when the application is no longer used by the business - potentially many years after the initial development.

I use the following slide to deconfuse confused folks:

These days the SDLC is typically iterative in nature, but so is the Application life Cycle! As the business responds to an ever changing environment, we start yet another ALM cycle to update, enhance the application and redeploy so the business can realise the benefits.

It's really that simple.