From 12:00 AM CDT Sunday, October 17 - 11:30 AM CDT Sunday, October 17, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Which sw development life cycle model / principles you use for labview development?

Hi,

 

just wondering what is the approach of the community in this question. My experiences:

 

  1. Waterfall model: I have never ever participated in a project which could use the waterfall model as it is defined. My customers - both internal and external - were unable to define the software completely at the beginning so the projects keep changing during the development. I like milestones part of the wf model cause it at least forces the customer to provide some kind of requirements documentation. 
  2. Iterative waterfall
  3. Agile/Scrum: I like the part that it does frequent releases, but this also encourages customers to be lazy with the definition at the beginning and assuming that you can magically adapt to every new requirements falling down from the blue. Also in many cases you can release small parts of the project simply because the small parts on their own dont too much of a value. I have seen many projects either failing completely or being the subject of a complete rewrite. I have successfully used this when developed rather small test routines for R&D departments where a series of modules used to validate the design but the modules themself were really smaller scaled projects on their own, with little dependency to each other.
  4. Kanban: I have only used it and only seen it to be used as a visual ticketing system. There could be more in Kanban but never experienced it
  5. Adhoc coding: sad but by far this is the most commonly used "method" I have seen.

 

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?

Message 1 of 8
(329 Views)

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.

-Santhosh
Semiconductor Validation & Production Test
Soliton Technologies
NI CLD, CTD
LabVIEW + TestStand + TestStand Semiconductor Module (2013 - 2020)
NI STS for Mixed signal and RF
0 Kudos
Message 2 of 8
(303 Views)

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.

 

========================
=== Engineer Ambiguously ===
========================
Message 3 of 8
(288 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 8
(271 Views)

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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 5 of 8
(214 Views)

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.

Message 6 of 8
(202 Views)

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 7 of 8
(191 Views)

Thanks for the feedback. Its somewhat relieving to know that the experiences are similar.

0 Kudos
Message 8 of 8
(108 Views)