Introduction


In this chapter, you review the certification steps and how Sun grades your submission. Unlike the other objective exams, the Sun Certified Java Developer (SCJD) exam is a software development project. As such, you are more likely to do well if you approach it as you would a real project at work or final course project at school. That means you need a plan, and this chapter helps you write one. Take a long morning to think your development plan through, and you'll be glad you did. The design of your solution can take days, but first, plan your project. This step is easy, and it helps keep you on schedule. I realize most people wing it and don't write a plan. That is fine for them, but the idea behind the SCJD certification is to demonstrate your competence at completing a software development project. This chapter reviews the most important aspects of managing a development project. Each exam aspect introduced in this chapter is covered in more detail later in the book, so consider the following material a quick map to completion.

Your SCJD plan should be simple; you aren't building a Mars probe data management system. However, the main elements of a software project plan are required for projects of any size, including your small certification project. This plan includes the minimum documentation a small software project should produce. Avoid the temptation to build it ad hoc.

Having a sound software development methodology divides professionals from the amateurs. Just recently, I was brought on to a seven-figure software project as the technical head. Even before I saw the code, red flags were waving before my eyes. From a project-management perspective, a lot was missing from my short list of "must-haves or failure is guaranteed ." As I was bearing down on particular missing items, the development team I inherited started objecting and pointing the "he doesn't know what he is doing" finger at me. They had been on the project for a year, so I lost all credibility. After all, there were quite a few of them, and I stood alone as the incompetent newcomer.

The client was oblivious to fundamental cracks in the project and elated with all the pretty screenshots and pages of marketing geek-speak paraded by the original development team. The client even broadcast a press kit announcing the soon-to-be software marvel as the key piece of its national initiative.

This project further convinced me of how necessary the requirements documents, design specifications, and testing plans can be. Because this project was missing these key elements, it became one giant, expensive piece of junk.

When I finally studied the code, it scared me. No, not because it was bad, but because it looked great. The style was clean. The modules had descriptive names . The coders seemed to have a good sense of programming. I couldn't understand how this much talent could go so far without requirements and designs. Long story short: There were so many problems that I couldn't keep up with user complaints, and the client killed the project a year later. A postmortem revealed that a poor design left a lot of good code sitting on a bad foundation. It could not be fixed because the problem was too deep, so they would have to start over.

This anecdote illustrates how proper project management provides essential guidance. In particular, use proper methodology for the certification assignment to help you produce a reliable and cost-effective (in terms of time) product. Also, good methodology can help you with bug tracking, code control, and documentation. Whatever way you go, make sure your approach is consistent with industry best practices for the software development life cycle.

graphics/tip_icon.gif

Do not write code for this project (or at work) unless you have a requirements document, even if it is brief and in rough form. If the project owner can't give you that, you are wasting your time. This advice includes prototype work. The implication of not having requirements is that management has not committed to the project, so what you code might never see a production server. If you don't write a small requirements document for this certification project, that means you didn't carefully read the instructions and are likely to make mistakes; you could possibly miss a key requirement and face an automatic failure on the exam.




JavaT 2 Developer Exam CramT 2 (Exam CX-310-252A and CX-310-027)
JavaT 2 Developer Exam CramT 2 (Exam CX-310-252A and CX-310-027)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 187

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net