<img height="1" width="1" src="https://www.facebook.com/tr?id=1101141206686180&amp;ev=PageView &amp;noscript=1">

Creating a Proof of Concept for LabVIEW Projects

(Circle of LabVIEW: Part 2 of 6)

This is Circle of LabVIEW: Proof of Concept, the second of a series of blog posts that describe different stages of the LabVIEW project life cycle from idea to market. Although reading them in order will help understanding the bigger picture, each blog post is self-contained with a small section regarding the “RT Installer,” a kind of sample product used in this series.

Following the previous blog post on the conception stage, where a basic idea for a product or project is hammered out, this blog post focuses on fleshing out that idea into a proof of concept or minimum viable project.

Although every project is unique, like during the conception phase, there are a handful of binary decisions that drive how we approach a project, more specifically how we estimate, organize project phases and mitigate risk. During this phase of the project lifecycle, we ask the following question:

“What do you need to get this project or product functional enough?”

We generally ask the same question in many ways to get a feel for what the client is willing to risk and what we can reasonably provide; some sample questions are:

  • What’s your minimum viable product?
  • What features could you do without?
  • How confident are you that your idea will work?
  • What’s your time budget?

Depending on the current stage of the project, they may be well past this point, or the project/product may just be an idea.

When trying to bring a product to market, often the market has a short window of time where putting forth the effort and it being profitable comes with constraints such as:

  • Our competitor won’t be able to bring something to market for two years, so if we can bring it to market within a year, we can corner that market for at least a year and make it worth it for us.
  • Or I don’t even know if this idea will work, but I have a set budget I can invest to find out and try to convince stakeholders to greenlight more budget.

At this point, we try to focus the scope of the project to an amount that’s admissible; we want the client to be able to validate their projects and products as soon as reasonable. Validation is when the stakeholders can confirm whether the project/product fulfills the reason they set forth during conception. A minimum viable product/project checks all the boxes and can give us a general scope to begin the requirements process.

Once the conception phase of the "RT Installer" was complete, as developers, we had to decide the minimum scope necessary to make it useful to our target end-user: developers. We concluded that for this to be worth it, it would have to provide existing functionality for software deployment to RT targets without explicitly using NI MAX or the RAD utility.  We settled on the idea that we must be able to perform all the functions programmatically through the System Configuration API and came up with the following basic functions:

  • Installation of a software set
  • Installation of a startup application
  • Programmatically setting a startup application to launch on boot
  • Installation of an FPGA application
  • Configuring of network adapters

We’ve included working example source code of this basic functionality; with these proof of concepts, we could move forward, confident that our idea would work.

 Download the Examples codes below:

 

Artboard 1ERDOSMILLER_RTinstaller-CTA