Hi All, I have recently bought three SUN Certification vouchers (very cheep). These vouchers are getting expired on 31st JAN 2008. I thought of using these vouchers for SCEA. Now knowing that the vouchers will expire in ONE month, could you please help me plan my certification process (in simple words save my $$money$$)? I am planning to write SCEA PART 1 by JAN 21st and I hope to clear it. Now I will have exacly 10 days to utilize my vouchers (other two). Now I am confused so as to how do I go about "Registering" and "Differring" and "Downloading" the exam?
Hi tanveer, I too am in similar situation but with me the case is I have cleared the SCEA Part I on 21st December and Have already downloaded the assignment.I have one voucher which expires on Jan 31st.Before that I will submit assignment and write Part III. I would suggest you one thing You prepone your Part I exam and then once you write it immediately get the assignment for part II. I am not sure whether you would be able to use voucher for Part II. This needs to be purchased separately. All the best. Do come Back ?You could mail me at firstname.lastname@example.org
I'm currently taking part II and have read some of the posts here. Some people did give out a description of their layout but in general go with what you feel is right e.g.
Introduction to your document Introduction to J2EE and why it is important (like how it solves TX, security...) Project Overview - what are the requirements that you've extracted - what are the requirements you've deduced (you will have to clearly put these in an assumptions list) Overall Design - main building blocks, and why - hints to technology you could use - mention of tiered architecture and how your building blocks will spread across (or not) - Main Generic Class Diagram A J2EE Approach - the component diagram - more specific diags if you feel like it - how to apply J2EE patterns, where and why - the sequence diags Deliverables - a summary of all the assumptions - all the required diags clearly labelled
This is just a rough draft to get you and others going. It's not the word of God (if only... I wish)
The bet of luck to you!
No matter what they say in Ohio, we're still first in flight!
posted 12 years ago
Thanks David. Following your hints I have come up with my format. My motto would be to come up with a simple yet intellegent document. I would assume the grader to be an intelligent and intellectual person and would not try to hurt his/her intellectuality.
OVERVIEW What are the requirements that you've extracted/deduced. What assumption you have made to deduce those requirements. How those requirements affect use case (If at all)
REFINED USECASE Only if there was a use case which was affected because of assumptions. You have to back this with some solid arguments. It would be better if it does not cause a deviation in the business process. It should not contradict anything not even your assumptions. If you are able to convince the grader with your arguments you will get good score (Good impression). If you fail to do so, you will loose some marks. A risky thing to do I think.
DELIVERABLES - a summary of all the assumptions
CLASS DIAGRAM - Main Generic Class Diagram - Basic building blocks, and why (Incase you have used something like swing for UI and you just want to show how the UI rendering works for example).
COMPONENT DIAGRAM. - The component diagram - More specific diagrams if you feel like it (Incase you have used something like swing for UI).
SEQUENCE DIAGRAM - the sequence diagram - Specific sequence diagram (Incase you have used something like swing for UI and you just want to show how the UI rendering works for example).
CONCLUSION - How to apply J2EE patterns, where and why (It should be brief) - Hints to technology you could use (Only if it remarkably different from day-to-day technology.) - mention of tiered architecture and how your building blocks will spread across (or not)
So guys could you please comment on refinement of the use case? And Do you think something can be further added or removed?
The outline looks good. I agree with your comments on refined use cases. It's better to avoid refining any use cases and stick to requirements provided. The list of deliverables you moved to the middle which looks kind of odd to me. David put that at the end of his list, which seem more appropriate to me.
David, Are you saying that the assumptions should be listed twice, once in the document for which this outline is provided and once in its own separate document?
What is the value in providing following: Introduction to J2EE and why it is important (like how it solves TX, security...) This doesn't seem to be relevant as the answer would be a standard boilerplate text. This is not something as a architect you are designing.
SCEA, SCBCD, SCJP
We noticed he had no friends. So we gave him this tiny ad: