Depending on the application ...
1) Identify Hardware
2) Identify Requirements
3) Build Back End Modules
4) Build Front End Modules (not gui)
5) Build GUI
6) Build Top Level Modules
1 - Simple. Identify what you need or at least what you plan to use.
Some questions I ask myself:
How is it going to be used? What makes it tick? What do I need to note from a program standpoint?
2- Identify what the program needs in order to work properly. Not "Item A needs to be wired to item B" But more along the lines of "I need to sample this at this interval".
Some questions I as myself:
What are my inputs? What are my outputs? How do my inputs affect outputs? What needs to be done on a dumb level? What requires more brains or objects to program?
3 - Decide what is a back end function AKA building blocks. And start building them. As I build each piece I write a test program(s) to test the range and all functions associated to it. Once each block is built I write a master tester that tests everything AT THE SAME TIME to make sure it functions properly with everything else.
4 - Build front end modules. These are more along the lines of Input A causes behavior B. As I build once again I test to make sure behavior is met. Typically this takes the longest time to build. Once all is built I TRY TO BREAK IT (eg mashing buttons, providing false/corrupt input, disconnecting essential things [WHERE DID MY JAG GO!])
Some questions I ask myself:
What can break? If A breaks what can it affect? How to bypass bad behavior from broken inputs? What functions should be automated? What functions should have manual override?
5 - Usually ask the end user for items they want or decide for them. Although uncommon there are modules built here that regulate the front end modules as well.
Some questions I ask myself:
How can this be made the easiest for the user? How can X be taken care of automatically? How many presses/clicks does it take to do X? What information does the user ALWAYS need to see? What information does the user NEVER need to see? What information COULD the user see if it is out of range? (For example I could have a sensor value popup ONLY if it out of range)
6 - Usually along the lines of AI
Questions I ask myself:
What would the user do in the situation? Could I just record a response for this situation? How should the program change behavior if X Y Z? What can the program do FASTER then human? How can that be used to its advantage?
From a robotics standpoint:
I have everyone as a group do 1 and 2.
3 is left to newbies (teaches responsibility) with guidance of vets.
4 is usually done by vets with newbies learning.
5 is usually done by vets/mentors if time allows.
6 normally happens at competition
