Developing Requirements: The Cost of Getting It Wrong December 10, 2008
Posted by ekerry in Software Engineering with LabVIEW, old.add a comment
I had a thread on the LAVA forums brought to my attention on the topic of ‘What is your LabVIEW application development process?, Best and worst development practices?’ This thread prompted an interesting discussion regarding some of the common challenges developers face when tackling a large application.
One of the primary goals of creating this group in the new NI community was to foster conversation and dialog amonst those of you working on these large LabVIEW applications and to share your insights on what you’ve learned from experience – both good and bad. I’m excited to see that this same exchange is taking place in a number of different venues, including the thread that I stumbled across and the new wiki on LAVA dedicated to Software Engineering. http://zone.ni.com/devzone/cda/tut/p/id/7117
Several people mentioned the difficulty of requirements management in this thread. The consensus amongst software developers is that requirements gathering is a difficult art to master, but the fact is that it can be extremely costly if overlooked. After analysis of 63 different software projects at companies such as IBM, GTE and TRW, we can actually put a number next to the ‘cost of getting it wrong’
The fact is that LabVIEW often falls victom to oversight of requirements as well as a lack of due dillegence for other software engineering practices due to the fact that it is so commonly used for rapid prototyping of small applications. Too often, I’ve seen developers try to scale these initially small projects into much larger and more complex systems without giving proper thought to requirements and especially to code architecture. Good requirements are typically generated as a result of iteratations between prototyping and documenting the findings of prototyping, which then lend themsleves to proper archiecture and better insight into how an application should be designed and help developers apply sound software engineering practices to ensure quality and reliability.
If you’re interested to learn more about requirements management with LabVIEW, check out some of these links.
Is LabVIEW a Programming Language? December 4, 2008
Posted by ekerry in old.Tags: LabVIEW, programming language
add a comment
Is LabVIEW A Programming Language?
Yes.
As a LabVIEW fanatic and enthusiast, I commonly field this question from customers and text-based programmers on a regular basis.At first glance, graphical programming appears abstract and so radically different from C and similar languages, that for many it’s hard to grasp how this grid of wires and colored blocks could possibly represent code.
While studying for my degree in computer engineering at the University of Missouri, I regularly programmed in C++, Java, and spent many long hours in labs going through the painful process of writing x86 assembly and even VHDL.I was also an avid web developer and had written many programs in a combination of HTML, PHP and Adobe Flash for a research lab at the school.Sadly, I had never used LabVIEW or graphical programming, but I did have one friend who kept egging me on to try it out.He claimed it would make my life much easier and that I could do all the same things I was already doing in a fraction of the time.
When I finally learned LabVIEW after beginning work at National Instruments, it was like a whole new world had opened up to me.It all made so much sense and I found myself wishing I’d listened and saved myself many all-nighters in college.
If you look back at 1986, the year LabVIEW 1.0 was released; graphical programming was a part of the natural progression. Apple had just announced the first graphical user interface ever for the commercial market.The use of computers had previously been entirely through the command-line and it seems logical that only text-based programming was around up until then.
Enter graphical interfaces… enter graphical programming. It was simple at the time, but the concept of dataflow made the representation of information and the relationships between operations to be performed much more apparent and easy for someone without a programming background to understand. It took off and became the foremost tool for anyone who wanted to control a bench top instrument and perform analysis in software.
These days, LabVIEW has evolved dramatically. The abstraction LabVIEW provides still enables scientists and engineers to solve complex problems without worrying about lower-level details, but it still has the ability to control more granular aspects of your application and push that same graphical code down to the pin with FPGAs and embedded targets.What would’ve taken dozens of pages of VHDL can now be accomplished with just a few simple VIs in graphical code.LabVIEW is object oriented and open; developers can re-use libraries developed in .NET or other languages.Users can build professional, end-use applications for commercial re-sale.
The flexibility of the development environment even allows users to combine different models of computation within a single application.Dataflow can be combined with text-based *.mfiles or tools like Statechart to take advantage of the strengths of every paradigm.All of these different models of computations are compiled by LabVIEW into a single binary.
Because of the abstraction that is inherent to graphical programming and the investment we’ve made in the compiler, LabVIEW is even smart enough to perform optimizations in the background that result in performance that can often exceed that of text-based counterparts.This is especially true when optimizing applications for multiple cores, which is a growing concern as the personal computer continues to offer consumers more and more cores within a single machine without any significant gains in clock frequency.
At National Instruments, we even develop many of our software products and a large portion of LabVIEW itself in LabVIEW.For those of you who use Vision Builder, you’re using a LabVIEW application that spans roughly 5,000 VIs and is developed by a team of about 3 individuals.The fact is that LabVIEW is a programming language in every sense of the word and it presents users with more options and more flexibility than other monolithic environments.
Why do so many people still refuse to believe LabVIEW is a programming language?Perhaps after 23 years of development, LabVIEW is still just that far ahead of its’ time.
Share your thoughts on LabVIEW as a Programming Language! Leave a comment below.
