Wednesday, September 26, 2007

Flexability vs. Usability

I've had some family and work issues lately but I'm going to continue this blog, it makes me thinks about what's important in testing.

Lately I've been working with National Instruments PXI 6229 Multi-function I/O board and NI DAQmx drivers. Using DAQmx has made me think about flexibility versus Usability. First, DAQmx is a departure from the standard method of get a handle to a device and use it. DAQmx functions wants a DAQmx task to be created and used. The task is associated with a set of operations, whether they're Digital I/O, Analog I/O, counter operations, A/D operations, etc. The task is then started and runs however long it takes to complete or how long is specified in one of the many operations setups.

This allows the general DAQmx routines to operate on any type of board. The problem is usability. Not all boards support all operations. A Digital I/O does not support counter or clock operations. Not all operations are as clearly unfit as those. Also, it's not known whether the function will work on the board until the software is run and the function returns an error. The PXI 6229 that allows clocked operations but doesn't have a clock which disallows any "clock" DAQmx functions. (Clock operation require using the counter or an external clock on a PFI line) Things like this are not obvious. Another usability problem is that there are many clock functions and it's hard to tell which one is needed. When trying to operate the [nonexistent] clock on a 6229 it's not clear if the function itself is not usable in the situation or if the board does not support it.

The examples NI provides aren't for all boards. The examples won't run on all boards. Some of the Digital I/O examples won't run on boards with Digital I/O.

Overall, the flexibility the DAQmx functions allow inhibit the usability of the functions. NI needs to apply the KISS principle, Keep It Simple Stupid.

Thursday, September 13, 2007

The test development environment

This is less about computer development environment and more about physical development environment. In the past I've been in the unfortunate situation of going off-site to develop. It went slow and I got phyically sick at least once a week. This situation is about to happen again.

I bring this up because a test set we are working on is being sent to the customer's site. In the earlier parts of the contract the tests will be developed here. Due to the lateness of the UUT's being developed, the test development process will be moved to their site, where the UUTs will be. They originally promised to send UUT's for us to verify our tests in April 2007 but changed the agreement, rather ignored the agreement and changed what we had to do. That meant the we have to send a test set up to there site and the use their UUT's. The same UUT's that their engineers will be using at the same time we would like use them. Or maybe we have the midnight to 6am shift to use the UUT's.

This winds up putting all the pressure on us. We're in a strange place working the test set. If we need technician help we have to find one of there technicians to help us. Same with tools, seating, and, most of all, UUT's. We will be at their mercy on when we can use the UUT's and guess who will be at the bottom of the priority list for use of the UUTs. (answer: us)

The only good thing about this situation is we will have at least some access to the UUT's to complete our test verification. Nothing else is good about it. We'll be out of our environment, staying in hotels, away from family, and eating out all the time. It gets old quick.

As for me, I'm only going up there occasionally, I can get my stuff done down here. Since I'm a single dad, it would be tough for me to go up there for 3 months like some of the others.

Have a great day

Tuesday, September 4, 2007

NI and Education

I'm currently involved with the Grand Prairie Independent School District (ISD) to help develop academic programs for a Technical High School currently being planned and built. When we started I found out, to my dismay, that GPISD only had a simple Intro to Engineering class. They do have a programming class under the area of business and an electronics class under science. But nothing to lead people into engineering. I was appalled at the lack of Engineering curriculum.

Now, I'm interested in helping them get some engineering programs in place for the new technical high school. I was looking at what academic information NI has. They have an NI Academic area on there website. It is mainly LabVIEW based if that were a surprise.

They also have NI ELVIS which a LabVIEW based electronic is an integrated design and prototyping platform for engineering and science laboratories to teach concepts in measurements, circuits, controls, microcontroller, and embedded design. It is a bit pricey for high schools and I think targeted to colleges.

Hopefully, the GPISD can afford to put in place a good engineering program. Whether they can afford NI or not is yet to be seen.

Project lead the way is a good, somewhat canned engineering curriculum. There are other school districts that use Project Lead the way and GPISD will probably follow suite.

Well, have a good day.

Sunday, September 2, 2007

Requirements help from NI

NI has a product I'm looking at right now. It's called NI Requirements Gateway and it's to help keep track of requirements. It won't help deal with poorly written requirements like "The user interface shall be easy to use by anyone". It will help you track the requirements from the requirements document to the code. Whether the requirements are simply documented in MS Word or MS Excel, or kept in a requirements database like DOORS or Requisite Pro.

I'm dealing with requirements written in MS Word. Specialized MS Word tags (similar to tags like Heading 1) can be put in the requirements document. Then the complimentary tags can be placed in TestStand and down in the code called by the sequence step. NI Requirements Gateway then extracts the tags and follow them down to the code. I know it works with TestStand, LabWindows, and LabVIEW. All NI Products, and figuring NI is doing what they do, I bet it can flow down into other languages, like .dlls built in C++, though I'm not sure about that.

It can come up with a requirements traceability matrix, a table to easily trace the requirements from the document, to the code. It assumes the requirements are specific and not vague, general requirements like the one above. But for real requirement it helps prove the requirement was implemented.

Happy Requirements tracing.