09-09-2021 07:50 AM
Hi,
just wondering what is the approach of the community in this question. My experiences:
I have been developing lv apps for 15+ years and I guess I have never seen any labview project in which the development followed any given life cycle model. Most of them had elements of pretty much everything I know without properly estabilished rules. Even if there were set rules they were pushed aside really frequently. I've seen that in large and small companies and I have seen that as full time employee as well as a contractor.
I had the following conversation at least... well pretty much countless times:
Manager: Jesus Christ / bloody hell we have a serious!!!!! issue we need to address immediately.
Dev.: sure man, tell me about the problem and lets work out the best solution.
Man.: what? There is no time to talk it thru! Just solve it right now.
Dev.: but you recall that we agreed that we will follow certain programming principles, right?
Man.: sure, and I really appreciate your mindset which will bring our company to the next level by setting well defined methods. Unfortunately we dont have time for that, we need the fix ASAP. So start immediately
Dev.: duh... whatever...
Wondering whats your experience?
09-09-2021 08:43 AM
I would say, I have seen almost all the 5 models you've described. The adopted model depends on the kind of project.
Some projects have to start as an MVP and slowly build up features based on demand.
Some projects have very well defined requirements and timelines.
Some projects are relatively short and ad-hoc based on small requirements.
Some projects are just maintaining a long-running project.
I have worked on projects on a hybrid Waterfall and Agile model, as rare as it gets, some LV projects have well-defined requirements, just not decided when and how to implement the requirement.
09-09-2021 09:32 AM - edited 09-09-2021 09:39 AM
Well I am basically the entire development team... If I am really lucky I will get a test plan but that is rare, most times I am just given a set of specifications that our product must meet. Then I am tasked to come up with a way to test that. Including writing the test plan, specifying and buying test equipment, construction of test fixtures (With some occasional help from Mechanical Eng) and of course programming them and then maintaining both hardware and software until the end of the product life.
09-09-2021 10:05 AM
@RTSLVU wrote:
Well I am basically the entire development team... If I am really lucky I will get a test plan but that is rare, most times I am just given a set of specifications that our product must meet. Then I am tasked to come up with a way to test that. Including writing the test plan, specifying and buying test equipment, construction of test fixtures (With some occasional help from Mechanical Eng) and of course programming them and then maintaining both hardware and software until the end of the product life.
That is generally my life as well. I will write up the test plan and procedure while also figuring out equipment and designing my rack and interfaces. I am typically also in charge of the test equipment and cable fabrication. I was lucky with my last major project to have an amazing fabrication technician. So while things are being put together, I am coding up the test sequences based on the test procedure. Once my test system and the first UUT are done being built up, the fun really beings: integration.
09-10-2021 05:55 AM
The waterfall model is an ideal model case that seldom really happens. We have tried it with customer projects and the requirements discovery phase to create the necessary detailed requirements specification easily can take up a very significant amount of development time without usually the expected benefits of quick and easy implementation as the requirements start to change during development anyhow as more insight in the whole process is gained.
Most of our projects tend to follow more of a V-model and usually in an iterative way, going more than once the full cycle. Depending on the experience of the programmers involved this can work quite well when the different submodules are properly modularized and only interact through well defined interfaces with each other. Even significant modifications to the whole application can then be implemented in a fairly straightforward way in subsequent iterations.
09-10-2021 07:15 AM
Up until recently the company i work at had a loose set of specs and a set timeframe we were supposed to follow (i guess this is adhoc based?).
The specs kept changing, so much so that the timeframe set was impossible to follow (in worst case turning a 6 months project into a year and a half one). Due to large influx of new employees it also became harder to keep track of who knows what.
Due to this, since the beginning of this year we adopted scrum model and RACI matrix for each project. The projects are also way better defined and all departments are involved at the creation, to provide their input. I like this way better, it's easier to navigate... BUT since the projects are now so well defined it's a real pain in the ass to change some specs... so it gets booted down the line for the next project to deal with.
09-10-2021 08:30 AM
For test station SW development, my company generally uses the Haphazard Principles and it works quite poorly for us. Except that's just a guess because we have no real metrics to evaluate ourselves.
09-14-2021 09:05 AM
Thanks for the feedback. Its somewhat relieving to know that the experiences are similar.