Overview and some key points on SCEA 5.0

1. SCEA 5.0
July 2, 2011 PRATEEK JAIN
1

2. Thought of something which…
Equips you better by bridging gaps between knowledge and carrier path.
Proof of your capabilities.
Increased confidence.
Gain client’s confidence easily.
Better opportunities/say in design decisions.
Better growth opportunities.
2

3. Why am I here?
What is this SCEA?
Share my experiences.
Tips and Tricks.
Benefits of exam.
3

4. About Exam
Composed of three parts
Part one – 64 multiple choice questions
Part two – documenting a solution to a given business problem
Part three – defending / reasoning about your part two submission
Exam is the pinnacle of Sun’s Java certification
Reflects a strong desire to enable Java programmers to progress along the
career path to architect with well-defined goals
4

5. How to prepare?
What happens when 10K times a button is pressed?
What if something needs to be changed in production?
What if this feature comes back to you after 6 months?
Read a lot (not just about technologies but also code).
Know what industry leaders like Bill Burke etc. think.
5

6. Must know
All design patterns covered in “Elements of Reusable Object-Oriented
Software”.
Atleast all JEE design patterns covered at http://www.corej2eepatterns.com/
UML (version is not important).
Technology stack offered by Sun/Oracle.
6

7. Tips
Mock exams like here
Recommended books
SCEA Study Guide (Exam 310-051) By: Paul Allen; Joseph Bambara
SCEA Study Guide By: Mark Cade; Simon Roberts
Sample problems like,
Automate the assembly line of car making factory. Domain model will
be provided.
7

8. Common Mistakes
Not taking care of what is not written in problem statement like non-
functional requirements.
Design being inflexible for future changes in technologies.
Trying to use technologies specific to Sun where better alternatives like
hadoop, lucene etc are readily available.
Not being able to defend their design and technology decisions.
Incorrect UML diagrams.
8

9. Common Mistakes
Not taking care of what is not written in problem statement like non-
functional requirements.
Design being inflexible for future changes in technologies.
Trying to use technologies specific to Sun where better alternatives like
hadoop, lucene etc are readily available.
Not being able to defend their design and technology decisions.
Incorrect UML diagrams.
9

10. Question and Answers
10

11. Feedback
11