By "best practices," I mean the software-engineering methodology based on the principles and standards advocated by industry leaders , such as the Institute of Electrical and Electronics Engineers (IEEE). Following best practices enables you to earn the best marks on your certification project. Large projects have reviews, inspections, and audits , but they aren't necessary in a formal sense for this project. However, as with large projects, you do need to manage the artifacts, including configuration, software, data, and technical documentation. The software-engineering methodology prescribed for this certification project includes all aspects of the software life cycle. You start with project planning, and then move to producing code, conducting testing, writing the documentation, and, finally, submitting the project. Only the maintenance phase of the life cycle is missing from this project. These are the main steps for achieving the best score:
Other development methodologies are available. One is the Rational Unified Process (RUP), which has challenged the waterfall methodology IEEE espouses. You can find more about this excellent approach to software projects at http://www.rational.com/products/rup/. RUP supports a classic waterfall development process. However, unlike a strict waterfall activity arrow, RUP allows for iterations and for backward flow in the waterfall methodology. Another is Extreme Programming (http://www.extremeprogramming.org), in which the iterations are very short and efficient compared to the waterfall methodology. Component Based Software Engineering (CBSE) or Commercial Off-the-Shelf (COTS; see http://www.sei.cmu.edu/cbs/) takes advantage of preexisting components better than the other methodologies do. Please note that such third-party components cannot be submitted with your exam. However, some open source solutions can act as guides to certain parts of your solution. Jakarta has several projects that you can download and view the code, which may provide hints at how to solve some portions of your assignment. Finally, there is Open Source of Linux fame; however, this approach is inappropriate for the assignment; Open Source needs developers to coordinate efforts, but the certification assignment forbids such coordination. Download the AssignmentAs it plainly states on Sun's certification page, "Prior to beginning the Sun Certified Developer for Java 2 Platform program, you must be a Sun Certified Programmer for the Java Platform (any edition)." Certification consists of two parts. The first part is the Programming Assignment (CX-310-252A). The second part is the Essay Exam (CX-310-027). Use the following steps to download the Programming Assignment part of the certification exam:
Concept DevelopmentConcept development is the very front-end process of software development. In this case, it begins with Sun's instructions, which specify the need for a new software system based on a few base classes included in the assignment download. However, Sun goes only so far: It supplies skeleton classes and a few requirements. From these pieces, you have to conceptualize and assemble the complete solution. Then you figure out the best way to perform the work. Planning and SchedulingIf you don't have a good plan, completing the assignment takes longer and you risk failing the exam. This section offers a plan that will get you to the end smoothly. The schedule is intended to give you guidance in identifying and preparing your project submission. This way, you eliminate the chance of failure caused by a boneheaded mistake, such as forgetting to include user documentation, the README.TXT file, or a particular requirement. By following this schedule, you can achieve the assignment objectives faster and better, and still get some sleep. The 100- hour schedule in Table 1.1 offers a general list of tasks you should complete. I've read the forum posts from a supposed guru who did it in two weeks in his spare time. Perhaps he had recently completed a similar project, or maybe this genius is that much smarter than everyone else. I wouldn't hire this cowboy, however. Please use the industry's best practices and include all the steps. Although you shouldn't skip steps, you can trim some time here and there. If you follow this plan, you'll do great on the certification project and further polish and demonstrate your software project management skills. Table 1.1. Assignment Schedule
These tasks are done top to bottom, as listed in Table 1.1. However, don't follow the list blindly. For example, documentation (step 9) should be done throughout the project; don't wait until the very end. Also, steps 5 to 7 are done repeatedly. The time estimates help you gauge your efforts, but your approach to completing the assignment directly affects the number of hours needed for each step. Some candidates don't spend much time planning and designing. If you are highly experienced , you might complete the assignment in under a month. Some candidates take the time to thoroughly understand the assignment and take several months to craft their solutions. Just be aware that developers tend to underestimate how long it takes to accomplish a task. Doesn't the download take only 5 minutes? No, it doesn't. The first time you try to log in to the CertManager site, you have to get a password. After you finally download the assignment, you still have to unpack the download JAR and place files in a proper directory tree. Take your time because if you make a mistake, you might have to beg a favor from Sun to upload again. Requirements DefinitionThe requirements definition step involves writing the Software Requirements Specifications (SRS), which should precisely describe each essential requirement of the software and the external interfaces. Consult the ANSI/IEEE Standard 830-1998 (http://standards.ieee.org/reading/ieee/std_public/description/se), "Recommended Practice for Software Requirements Specifications," as a model, and tailor it to your needs. Somebody went to a lot of trouble to think through this standard. You can tweak it, of course, but the model is a good base for writing your requirements definition. Whatever you come up with, your specification should include all the details you, or someone else, needs to create the design. The SRS establishes the contract between you and the Sun evaluator on what the software product is supposed to do. Break this contract, and it is an automatic failure. The instructions in the download sketch out the requirements in not-so-obvious ways. Your challenge is to read through it carefully and make sure you pull all the requirements from the instructions and the source code comments. That's right: A few requirements are buried in the javadoc comments. For example, for some candidates, a requirement hidden in the supplied base class code specifies that only the owner of a database lock should be allowed to unlock the database. This requirement is certainly not obvious, so many people overlook it and lose points on the certification project. The following is a loose adaptation of the IEEE standard 830-1993, "Recommended Practice for Software Requirements Specifications" (IEEE provides 830-1993 at http://standards.ieee.org/reading/ieee/std_public/description/se/, but not 830-1998):
The order of items in section 3, Specific requirements, is flexible. The standard suggests many ways to organize this core section of the SRS. The preceding example is just my own. You can arrange it how you want; just make sure you include all the items. For the assignment, you need only a sentence or two for the main items. This step forces you to think through the project requirements. For example, for portability you might state: "The solution must work on Unix." Remember, the evaluator may test your project submission on Unix, Solaris, or Windows. If you are developing on another OS (I'm using Windows 2000), this one requirement should prompt you to test your solution on Unix before submitting the project. Testing is especially important for this assignment, as part of the solution must read/write to a file. File handling is a little different among OS file systems. In particular, the file path separator is different ( \ in Windows, and / in Unix), so the best approach is to use forward (/) slashes for all paths, and Java will automatically handle translation to Windows path format if the program is running on Windows. If the evaluator cannot open the database file supplied in your uploaded assignment, it means an automatic failure on the exam. Don't let the lowly slash doom you! Functional DesignThe functional design step is optional. Most software development shops do this step as part of the detail design, not as a separate document. If you want to perform this step, it is time to develop your functional design document, which defines the system's functions in user terminology, not geek speak. For the certification project, the functional design should define only a dozen functions because the assignment is no larger than that. It narrows the scope of work to just these functions, which later become the foundation for the detail design. The functional design is written from the user's perspective. You can write a draft functional design document by following the instructions in the assignment download files (see Chapter 6, "Application Analysis and Design," for more detail on this topic). For example, the traditional assignment for this certification is a reservation system. (This is no secret; just read the thousands of posts on the subject.) One of the functions you need to build enables the user to reserve seats, so this part of the functional design might be stated as "The user will be able to indicate the number of seats needed for the reservation." Detail DesignThe instructions that came with your assignment download describe the system you are to build. In this document are items best described as functional requirements. From these requirements, you can write a short detail design document. The idea is that applicability is not restricted by the software's size, complexity, or criticalness. Follow the IEEE standard 1016-1993 (http://standards.ieee.org/reading/ieee/std_public/description/se/), "Guide to Software Design Descriptions," which has the following outline:
This document is a detailed description of the classes and methods of each software component. It is very concise and is used by programmers to guide them in building the actual code. ProgrammingWrite code using a style that is acceptable to Sun. This step takes the most time, but if you did your design properly, it is easier than the tasks you've already done in the preceding steps. Most of the book expands on this step, so I'm mentioning it only in passing here. TestingSubmitting your solution without proper testing isn't smart. Many people have done this and had to pay another $250 to take the exam again, all because of a simple mistake that could have been caught with proper testing. Follow the ANSI/IEEE standard 1008-1987, "Standard for Software Unit Testing" (http://standards.ieee.org/reading/ieee/std_public/description/se/), which has the following outline:
This document describes a testing process that includes phases, activities, and tasks. It also sets a minimum number of tasks for every activity. While the assignment is not large, the above document can provide assurance that the each unit in your submission is properly tested. Even if you don't complete a full document, it is helpful to at least use part of it. Installation and AcceptanceYou should definitely test your application on Unix. Your evaluator might be using Solaris, Sun's flavor of Unix. One of the concerns with portability is the database and user documentation location. The path separator differs among the various platforms; for example, Windows uses \ and Unix uses / . It would be a shame to lose points because the evaluator couldn't pull up the user documentation. Develop the application on your platform, but before you submit it, run it on Unix once to make sure all is fine. DocumentationYou must submit ample documentation with your certification project. The documentation includes javadoc, a README.TXT file, user help, and a design choices document, which explains why you designed the project that way.
Javadoc CommentsIf you are new to javadoc, it is the Sun Microsystems tool (http://java.sun.com/j2se/javadoc) for generating application programming interface (API) documentation in HTML format from document comments in source code. Writing javadoc comments can become an entire project in itself, and you need to do a fair job at writing comments because Sun does review them. The javadoc comments are enclosed in the multiline comment. The text must be written in HTML; must precede a class, field, constructor, or method declaration; and must be structured as a description followed by block tags, such as @param , @return , and @see . This documentation is part of your grade, so don't be shy about commenting your code. Every class and method should be commented in such a way that javadoc can grab it. While you don't have to use the full complement of javadoc tags, you do have to comment to some extent every class and method. README.TXT File
You must create a single text file (plain ASCII format; word processor formats are unacceptable) called README.TXT. Place it in the root or installation directory of your project submission. This file describes to the evaluator the following information in exactly the order listed in your instructions. This is the structure I used for my README.TXT file (see Chapter 5, "Documentation & Javadoc Comments"):
User HelpAlthough it is true most developers wouldn't be caught dead writing a user manual, you have to do it for the exam. The evaluator only glances at the written user help, and it should be just a short page. The challenge is to write for users who don't care about the code. They just want to know how to operate the application quickly, without hassle. Therefore, you must include an online user manual in HTML format. Don't consider it the least important deliverable . The user manual is so easy to do that you might think of this portion of the exam as low-hanging fruit. I recommend you include the following:
Design Choices DocumentYou must also provide a file that documents your major design choices and the reasons for those choices. Include your choices of RMI versus serialized objects and modifying versus extending the Data class. This document can include some of the following optional sections:
Packaging and SubmissionYour project submission has to be uploaded as one JAR file. Anything else, including TAR or ZIP files, results in automatic failure. Your project must address the following questions. How do you arrange all the files within a single JAR? You can nest JAR files inside the main JAR. How is the evaluator supposed to run the application? For that matter, how is the evaluator supposed to get his hands on the README.TXT file that explains how the evaluator is supposed to get his hands on the README.TXT file? The instructions in the assignment download will tell you this, but here it is again as a reminder: When you submit your assignment, you should provide the following parts:
I've read that some people have created an elaborate directory structure, but don't do that, or you'll be asking for trouble. In fact, if you have more than five directories, you will likely irritate your evaluator. The directory structure can be as simple as this:
Don't complicate it. You shouldn't have more than four directories, and three or even two will do. You take the chance of making a mistake if you use too many directories. Software MaintenanceOn a production project, the software maintenance step is where you provide support, work on bugs , and start working on the next version. After you submit a certification project, what are you supposed to do with your code and files? Hang on to them for a while, or at least wait until you get confirmation that you passed. If you fail (which is not the end of the world), you can reexamine the score breakdown and fix the low-scoring section. Remember that you have to pay again to resubmit your fixed certification project.
|