Tip:
Highlight text to annotate it
X
Welcome to the Demonstrated Functionality for the Certified LabVIEW Developer exam presentation.
My name is Mark Ramsdale, I'll be your host today.
This demonstration will cover the ATM sample exam for the CLD test.
We will be looking at what is meant by Demonstrated Functionality.
And, in this, we will be seeing how the application is judged to have met the requirements of the exam specification.
For every exam, there is a specification requirement document. It details all of the requirements,
such as the front panel, and the behavior of many of the controls, the behavior of the model.
I'm sure that most of you have seen this many times as you've been studying very hard preparing for the CLD exam.
Similarly, for every exam, there is a functional test matrix.
This is a form, that is developed alongside of the specification, and it covers all of the specification requirements for the exam.
It is used to evaluate, on a pass/fail basis, the multiple demonstrated functionality checks within an exam.
We have high categories, such as Initialization or card insertion, which is specific to the model of the ATM,
and inside each category, there are sub-categories.
You can see that there's a Pass/Fail test on each of these Demonstrated Functionalities,
and, depending on the number of passes or fails within a category, the category will receive a certain number of points.
In this example, I've normalized everything to 1.
There is a message given, whenever there is a failure within a category.
If there is one failure, or multiple failures, the same message will be given for that category.
You can see here, as I'm showing you, for the ATM, there are many checks made, these are all based on the specification.
You've seen how the functional test matrix provides a detailed list of the demonstrated behavior required for an application.
This is an objective review of the CLD exam's behavior:
How does the application respond to the inputs and outputs? In what order? Does it meet what the requirements expect?
The result, then, becomes the same between different graders.
and, between the candidates, there is the same level of requirements that must be achieved.
There's no subjectivity on the part of the grader
as to whether or not the exam performs or doesn't perform a specific requirement.
The results have to be demonstrated on a category and sub-category basis.
Keep this in mind, when you're thinking of documentation, a very important part of the CLD exam -- under the documentation
However, within the Functional requirements, documentation is not considered part of the requirements.
What the exam intended to do, what the application was supposed to do, or what it could have done, is not part
of the evaluation of the functional behavior.
Now that we've reviewed Demonstrated Functionality as a grading method for the CLD exam,
let's talk about some suggested strategies for taking the CLD.
Get started with a functioning main application.
After you've decided what architecture you're going to use, get the architecture ready:
Make sure it can start and stop, make sure that it's ready to have modules put into it.
Then, perhaps, move on to functioning file inputs and outputs ... and timing.
You're guaranteed to see file IO requirements and timing requirements in your exam.
A safe bet is incremental functionality based on the model requirements.
Many applications have functionality that builds on previous steps.
For example, in the ATM, if you can't log into your account, you certainly can't make deposits or withdrawals.
Most importantly, know your style.
What you know about the demonstrated functionality evaluation -- work that into your style.
If you have a comfortable method of approaching a project and completing it, please continue to use that -- and
think about what strategies you might adjust your style with,
based on requirements for demonstrated functionality.
Thank you very much. and as always, if you have any questions, please send an email to Certification@NI.com