This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Like those who preceded me, I too would like to report my successful completion of Parts 2 and 3. Without cutting and pasting my results directly from the certmanager site, I did score well into the 90's on the exams so I am pleased with the result.
I only lost a couple of points on the Class Diagram - I thought it was complete and so did the grader but the grader also found some aspects of it to be unclear or incomplete. As we all know, because no feedback is given, we'll never know what they thought so, oh well. Although the ambiguity of the assignment is very realistic in simulating a "real world" project environment, the lack of feedback on the assignment is disheartening, especially for those who scored poorly.
With that said, I only used 3 sources of information to prepare for the SCEA: 1. The ever-popular SCEA preparation book by Mark Cade 2. This forum 3. Google and the Internet
Mark Cade's book covers everything you'll need to know. However, having work experience with the concepts covered in the book is invaluable. The book served as a "Cliff Notes" of sorts to summarize the concepts and highlight their important aspects in a format that flows with how the multiple choice exam is delivered and the expectations on how to complete the latter exams.
Before beginning this path a month ago, I stumbled upon this site after a Google search and read though many posts. I found the amount of assignment information included in some posts surprising, in particular how to handle the association between Flight, Equipment and Seat or how to handle both a Web and Swing client. By the nature of these posts, it appears that some people are just looking for answers without really thinking through the issue at hand. In many cases, the people asking these questions should really ask themselves if they're ready for this assignment and the job responsibilities of being a software architect. We as developers, designers and architects need to be confident with our critical thinking processes and solutions to succeed. Sure, in the "real world", you very well may not be working by yourself, but sometimes you do so these traits are critical to your success.
Using the Internet, you can instantly find many examples of UML diagrams and solution architectures for many software products. However, remember that there are millions of bad search results as well. Get an idea of how to differentiate the good results from the bad ones and it will help to hone your own design and diagram skills and to help you approach your work from angles that you may have not previously considered.
My advice for Part 1 is to read Mark Cade's book - that's it. If you have a few years of J2EE experience, that should suffice. If you have minimal J2EE experience, read the book a couple of times carefully. There are some mock exams on-line but for the most part they tend to be more tame than the actual exam, but, the more preparation the better.
My advice for Part 2 and Part 3 is to trust your instincts, think your solution through and then think it through a few additional times. After that, take a couple of days off and then re-visit it and walk through your solution again. The most successful projects involve many iterations of delivery - this assignment is no different. Try it yourself and you'll see - it's a no-brainer.
Like others before me have mentioned, waiting for the final result is not optimal, but if you do your due diligence, design a complete and accurate solution architecture, prepare it in a professional manner and are confident with it, uploading the assignment and completing Part 3 is satisfaction enough since you know that you won't have to look at your solution for a while. Now that's just like the real world - I've worked on many solution architecture proposals in my time and after completing the final presentations, there's a delicate balance between forgetting about it and retaining the lessons learned.