Random Ramblings on LabVIEW Design

I've been thinking about projects and lifecycles (an exciting life I lead). I've flipped it round a bit and have been considering how a customer would like to see their software developed. All of the figures here are the result of extensive research and obviously I would never just dream them up....

Traditional Life Cycle Models

Waterfall

Every conversation about life cycles has to being here.

This is too boring and discredited to spend much time on, in short it doesn't work, never has, unlikely ever to.

V Model

This is used in formal programs and each step on the design side is matched by a corresponding test and feedback into the design documentation.

In real life I've never had a customer want software to be developed in this manner.

Prototype Model

This fits nicely into our general way of doing things.

A few more steps and we're there.

More interesting is when you add user requirements to each of these sections, I'll split these into Easy Requirements and Hard Requirements based on how easy or hard they are to define.

An example of an easy requirement is "Store the data in a database", a hard requirement could be "System should not slow down if you need to display 10000 readings". This type of requirement is unlikely to be found in testing (usually testing is done on nearly empty databases, with manageable amounts of data).

1. Initial Enquiry

Sometimes a customer will tell you what he wants, this can either be form of a requirements specification, test specification, existing system, meeting, product etc etc. Realistically we would hope to get 70% of easy requirements and 50% hard.

2. Proposal

To quote a fixed price you need to have a pretty good idea what you are producing, therefore a bit more information should be received at this stage, let's say 5% easy and 2% hard.

3. Order

Off we go, let's write some software!!

4. Quick Prototype

This is the design review milestone usually, and a good opportunity to get a few more requirements, easy 13% and hard 5% sounds about right.

5. Alpha Test

The Alpha test is an offsite customer approval test and another opportunity to garner a few more requirements, easy 10% and hard 10%.

6. Beta Test

Now we're at the pointy end of a project, the customer is beginning to use the software and now we are beginning to get hit by the enemy of all project plans....REALITY. Expect 2% more easy requirements, but 20% or more hard requirements.

7. Maintenance

Now it is in use and you will find usage issues coming to the fore, now if you've done your homework you shouldn't get any extra easy requirements (pertaining to the original job), but because the software is in long term use you are quite likely to run into usage requirements, these will be hard to define by nature and could be up to 10%.

Robert Glass says in his wonderful book Facts and Fallacies of Software Engineering

The most persistent software errors-those that escape the testing process and persist into the production version of the software-are errors of omitted logic. Missing requirements result in omitted logic.

Tut tut tut I hear you saying, this is a desperately unstructured way to write software, I'll put in a counter-argument. This is actually what happens, it might not be ideal but it happens! New requirements are usually generated when your software hits Real-Life.

It's nearly as difficult to write complete and accurate requirements as it is to write complete and accurate software. The truth of the situation is that a user will not fully understand their requirements until after the system is delivered. They just won't.

In the market we play in should we really expect our customers to be able to completely define their system?

The saving grace is LabVIEW is not a traditional language, with LabVIEW you can expose your software to Real-Life far earlier than traditional software. If you begin your project on the assumption that you are not going to be given the whole picture and design and cost accordingly you are onto a winner.

I have more on this subject, but it's not quite formulated in my head yet. I think this early exposure to real-life is actually a real intangible benefit of LabVIEW and worth more consideration.

I'm presenting Fabiola De la Cueva's excellent "How to Polish Your Software and Development Process to Wow Your End Users" session at NIDays UK, please accept my apology now Fabulous. I'm really not comfortable with public speaking, but am a bit more happy with the chaotic chat about the slides approach that seems natural to me. If it gets too bad I'll show the video of Fab doing it professionally.

See you at the QEII Centre or propping up the bar at the Westminster Arms (a pub with a division bell, so that MPs know when to go and vote)

heel veel liefde

Steve