Random Ramblings on LabVIEW Design

Community Browser
Showing results for 
Search instead for 
Did you mean: 

Software Life Cycles....the truth! (IMO)

Active Participant

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


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


Active Participant
The truth of the situation is that a user will not fully understand their requirements until after the system is delivered

Amen to that! And attempting to anticipate these requirements is virtually impossible of course.

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.

Whilst this is certainly sensible, I find that a software design with the right balance of scaleability for unforeseen requirements whilst preventing an unecessarily inflated development time is very difficult, and often customer-specific. Build in too much flexibility then your costs inflate and you get beaten by competition at the quotation stage. Too little and the final hard requirements become very costly to implement and consequently either kill any profit you hoped to make, or by refusing implementation you kill any relationship you had with the customer. Any thoughts on this quagmire Steve?

Westminster Arms

Get me a pint of best in, I'll see you there...

Thoric (CLA, CLED, CTD and LabVIEW Champion)

Knight of NI

I worked on a project for about a year and all it involved was "engineer X wants to be able to do Y with this software".  And the original design of the software wasn't very scalable in the first place.  I redid some things to make them easier to edit (subVIs of all things reduced my code by quite a bit), cleaned up a bunch of stupid bugs (like things being 1 indexed instead of 0), and was able to add most of the desired functionality.  But the featrue requests just never ended.  So a program that was just supposed to quickly look at some data turned into a full debug system.  It was a fun project, but it is a perfect example of not knowing what the specifications are until it meets reality.

This article couldn't be any truer.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Active Participant

One of the key things we do is to use properly designed databases (the whole point of all this design talk is to allow you to change the maximum functionality with the minimum effort). Configurable software is also key. I've talked lots about encapsulation etc. Enumerated types, Strict type defined data type. State Machines. Decoupling the user interface.

Having a wizard type interface helps (it minimises the amount of decisions you have to make at any one time, therefore making changes easier to manage).

Using the right tool for the job, my interfaces to databases are SQL, ladder logic for PLCs, I'm sceptical of any technique in LabVIEW that is trying to lever functionality where it doesn't belong. For example if I want to queue data I use queues, similarly it's always bothered me using a While Loop to store data in shift registers.

Look-up tables rather than maths based logic. Nested cases rather than complex logic.

Having a common method with other programmers in our company.

None of the above need result in complex software, I think you'd be shocked at how dumb and simple our standard template is.

Oh and we've not reached Nirvana yet, you've seen how tatty and knackered I look most of the time .

The pay-off tho' is in customer relationships, our maintenance cycle is extended (I say we're in maintenance from Beta), but because you are solving customer issues when they really want you, you usually have a much closer and more supportive relationship. From an efficiency point of view, I think this is where LabVIEW really shines.

Today, for example I was on-site for 6 hours and solved 7 usage issues (adding sort to a table and making searching more efficient, adding batch loading of files etc etc), This is big software spanning 3 laboratorys, with about 50 user interfaces on each lab. None of these were part of any requirements, but I have got contingency in the job to allow me to support them without worrying unduly.

Active Participant

Oh yes, I've had those projects before. Be wary of projects specified on the basis of replacing an existing system, the question we always regret not asking is why has the previous system failed.


What we do is use LabVIEW to phototype the GUI and show the customer if this is what He want to accomplish and as we develop we keep Him in touch ask ask if He has changed his mind?? or has any more features that need to be added??.Most of our GIGs dont have a written requirments.And most of our costomers want quick and dirty SW and LabVIEW is good for that and they Love it.We once told our customer that we should sitdown and write some requirment and He asked us who will pay for hours spent in writen the requirment.He said "I need working system not pappers."

Munch Love Steve.

Greetings from Germany

Certified LabVIEW Architect
Certified TestStand Architect
Active Participant

I think that's where we play, the trick is to get as much understanding as you can as cheaply and with as little risk as possible. The danger is that our designs become compromised because of this.

We do not give a fixed price until we have enough requirements to satisfy ourselves.

Active Participant

We do not give a fixed price until we have enough requirements to satisfy ourselves.


One day I'd like to experience such a project.

Active Participant

On the bright side, we've only had 2 projects in 15 years with extensive requirements and they were a complete nightmare. If there is too much detail it can be more "how to do it" rather than "what we require".

One thing that we have started doing is a fixed price feasibility study / requirements consultancy. It's fairly easy to sell this to a customer and very useful for digging out more requirements. (Note: as Glass points out..In his experience no feasibility study ever comes back as unfeasible)

Active Participant


Another great article as usual. Thanks for sharing your thoughts and experiences. I stay away from fixed price project, but when that is the only option I do charge tiem and materials for the requirements gathering face. I feel like that is the only way I can really give a decent estimate as to how long is going to take and the customer wins, because at the end of this phase they have a general idea of what is needed, a detailed plan of action and they can shop it around. I don't mind if some else gets the job. I then get to come back and do Architectural Reviews and Code Reviews and I still get to see the project being completed.

One of the things that I learn reading your book (Software Engineering Approach to LabVIEW) was to not have hard coded constants, use configuration files ro similar things to make your software flexible for when you get all those requests at the end. In fact, that is part of what I talk about in my presentation.

I am very honored that you are going to give that presentation and I would not worry at all. You will do great! I would love to be there and I hope someone takes video.

Good luck!


Get Going with G! at G Central GCentral
DQMH Lead Architect * DQMH Trusted Advisors DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?

Active Participant

HI Steve,

That last model looks like it shares a few traits with agile, which is pretty much what I  unofficially do day to day on a micro level, so in my opinion is reflected at project level also.


LabVIEW 2012
Active Participant

Apart from the terrible spelling on the generic diagram ("planing" and "analisis" I ask you!) I would tend to agree.


The only issue is that it can be an excuse for code and fix, so you need the design up front and some formality to keep that in-check. I also like the term defensive programming.