How do YOU develop software?

[kamocat]

I thought it would be fascinating to look at the different processes people use to develop software, to see how it varies.
IMPORTANT: I'm not talking about what you would recommend as a developing process. I'm asking about what you actually use. Think about a recent project you've done - what were the steps or stages you went through between when you set out to develop the software, and when you considered it a finished product?

Recently I set out to test some SHARP IR sensors. I was having trouble getting accurate distance based off the curve on the datasheet, so I decided I'd test the the voltage-distance curve to see what it actually was. (This was also an excuse to try out my new NI myDAQ.)

The first thing I did was define the features I wanted:

• once-click sample
• show history of sample: mean, max, min (graphed)
• sample 100 times per datapoint
• show graph of most recent samples
• auto-increment option
• log data to file

I then built my user interface (front panel): [first thumbnail]

Then I had to figure out the structure of my top-level program. I made a table to describe this. [second thumbnail]

Because some user actions cause multiple program actions, I chose a queued state machine for the structure, using an event structure to catch the user events and translate them into program actions.

In actually coding this, I make the structure first. I made the event structure, and set it up to catch all the events I wanted. I made an enumerated variable with one value for each program action, and a queue to pass that data. Then I actually set up each vase in the event structure and the case structure. There were only two instances where I felt I needed subVIs: in the data acquisition, and in the data logging.
So, I put up flat sequence structures as dummies, and finished the rest of my top-level VI.
Here's what it looked like: [third thumbnail]

So from there I made the subVIs. The logging subVI is actually not yet existing in this initial version, but it was complete enough that I could start improving the UI and catching bugs. The reason I still have this initial version at all is because it was the point at which I committed to my Git repository.

So, in between the initial version and the final version, I made some changes. I'll be perfectly honest - I did not update the planning documentation when I did so. I use the planning documentation to guide me in how to create the software, but I don't usually create end-user documentation.
I did some minor changes, like adding key bindings to the "sample buttons", and getting rid of the "log name" in favor of just using the "log filename". However, my major changes rooted from making logging more practical. I had two different SHARP IR sensors: a short-range one and a long-range one. I wanted to try an algorithm to use them together, to get more reliable results (their voltage-distance curves do not pass the horizontal line test - for most voltages, there are two possible distances). I had been trying to figure out a good logging scheme where I could combine the logs of the two sensors in one file. Ideally I would be able to read them together. I then remembered that I could simply log them together, so each would have data at the same distance points. That was the first major change - to test both sensors at the same time.
The second major change was in how I stored the data. I had been storing it as a cluster of arrays - well organized, but very inneffecient, because each array can be a different length. I realized I had to convert it to a two-dimenional array to log it anyways, and so I changed that to a two-dimensional array. This time, I made it a typedef, so that if I made further changes, I wouldn't break my subVIs.
I think the only change I made after this was to let the user keep trying to save the log until it worked.


NOTE: I programmed this in LabVIEW 2010, because that's what I got with my NI myDAQ. It is backsaved to LV 8.6. I can open it on my computer, but there may be some missing dependencies. If so, just click ignore, and you should be able to see most of the code.
Also, I actually do my documentation on paper. I can think better that way. However, for the purpose of posting this on a forum, I opted to type it in, rather than scanning my messy notes.


So there you have it: a very small project, completed in about 6 hours spread over two days. I think it's a fair representation of my software development process.
But what about you? What steps do you go through when you develop software?