 |
|
||||||||||||
DianeS wrote:
I'm planning on taking the test later this summer. Anything you feel you can share, would be awesome.
So as not to get in trouble, I will give some advice but not talk directly about the test. Instead I will relate it to the practice exam, seeing as everyone has that available.
3 Steps for success:
1) Take the practice exam...more than once
Sounds obvious (and I may be beating a dead horse...), but I know people that haven't taken the practice exam and didn't pass. Be able to regurgitate it and take it repeatedly until you complete in the required time. Heck, justmemorize the architecture in the sample solution so you can repeat it on the test! Although I didn't exactly do this, there is nothing that says you can't. Even if it's not an architecture you'd normally use, don't try to be a hero(see step 2). If it's what the grader wants to see and you can go in there and crank out a memorized architecture that fits the problem then DO IT! A dumbed down example of this is when preparing for my CLD I did everything Icould do memorize how to make a timer with a pause. Even if I thought I could recreate it on the exam with some thought, I memorized the stupid thing so I could do it in 2 minutes instead of 8 or 9. With something like anarchitecture, this time savings could become a difference of 10 minutes or 30.
2) Don't try to be a hero
You are not taking this test to prove what an innovative programmer you are. This is not a time for "groundbreaking" architectures. You are proving you know how to develop a scalable architecture in a quick amount of time. If aqueued state machine works, just use that! I would recommend not using OOP, because I find it to be too time consuming and the benefits don't outweigh the drawback of the time lost in a situation like this. But, that's just myopinion and some may be faster than me at using it.
3) Find the functionality portion of the test and go through that FIRST!
My first two suggestions could probably be found on any "tips for CLA success" blog or the like. But here is one I found to be helpful that no one really talks about. The functionality requirements take the most time to implementand effect your overall architecure the most. Start with these, even if they are at the back of the exam packet (like they are in the practice exam). Many of the UIrequirements are asthetic and a comment will suffice so savethose for last! I'm assuming the grader will be more forgiving if you write "[covers: blah blah] turn button red" versus "[covers: blah blah blah] Do initialization rutine here, see requiremetns for guidance!"
If you are in a time crunch at the end it's much easier to throw those UI comments in then be dealing with architecture/functionality. Also I found some requirements to overlap or be listed twice, say once in the UI and once in thefunctionality section (i.e. button functionality). Try to find these overlaps ahead of time and mark them in your test booklet. This way when you implement something that is in multiple sections of the requirements, you can add your [covers:] comment for each requirement that it meets while in that specific subVI. It's a major time killer when you implement something to meet a functionality requirement then an hour later have to go find thatimplementation again because a UI requirement is similar and will go in the same spot in the code.
Anyways, hope this helps and if you have more specific questions please ask!
|
||
|
||
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. |  E-Mail this Page
|
||
|
||