Software Project Management


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:

  1. Download the assignment

  2. Concept development

  3. Planning and scheduling

  4. Requirements definition

  5. Functional design

  6. Detail design

  7. Programming

  8. Software integration and testing

  9. Installation and acceptance

  10. Documentation

  11. Packaging and submission

  12. Software maintenance

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 Assignment

As 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:

  1. Purchase your assignment First, you purchase the Sun Certified Developer for Java 2 Platform assignment ($250) by calling 800-422-8020. If you reside outside the United States or Canada, you must contact your local Sun office. Sorry, the vendor of the world's most advanced software language has yet to offer this purchase online. After you pay for the assignment, you set up an account on the CertManager Web site, and then log on and download it, as explained next .

  2. Log in to CertManager Log into Sun's CertManager database (http://www.certmanager.net/sun/) and select Sun Certified Developer from the menu. This choice takes you to a page with the option to select the version of the assignment you want to download. The next page contains instructions on how to download the assignment. You are allowed to select an assignment once, as the button immediately changes from Download to Upload. If you make a mistake, exit CertManager and start again. Assignment instructions are given in the download's files. If you get stuck at this point, your only option is to email CertManager.

    To use the CertManager Web site, you need to log in using the Prometric Student ID (for example, your SSN) given at the time of your first exam. You create your password the first time you log in. If this is the first time you have used this Web site, you must register a new student account (http://suned.sun.com/US/catalog/register.html). After you have a user account, you can do the following at the CertManager Web site:

    • You can update your contact information, including your email address, phone number, and postal address.

    • You can view your certification history. For every exam you've taken, CertManager shows you the test name , date taken, pass/fail status, and score.

    • This site is the only way to download and upload the Sun Certified Java Developer assignment. You get the assignment here, develop your solution, and then upload it to the same URL.

    • You can view your progress on any certification. CertManager lists all of them and places a colored box next to each one. If the box is empty, you haven't started it. If it is green, the assignment is in progress (for example, between assignment download and the assessor's grading it). If it is blue, the assignment is complete.

    • In the event something goes wrong (for example, you upload the assignment, but it doesn't show up), you can submit an online help request to Sun's customer service. Actually, Sun posts only an email address (correspondence@prometric.com).

    • If you lose your username and/or password, you can get another one from the CertManager site. Likewise, you change them at the site.

  3. Download the assignment Click the Test History button at the left of the page, which displays your test history, as mentioned previously. Click the Assignment button on this page to get the assignment page, where you choose the Sun Certified Developer Assignment for Java 2 option and then click the Download Assignment button. Later, return to the assignment page to submit your solution by clicking the Upload Assignment button. Sun's Web site is clunky , and this process could be improved. It is easy to make the mistake of trying to download an assignment before you have purchased the exam. It won't work, but the Web site doesn't tell you what is wrong. If anything goes awry, please see your contact for each country at http://suned.sun.com/USA/certification/. If you have already purchased the exam but can't download the assignment, you should send the payment confirmation you received to Sun by using the comment box at the bottom of the screen.

Concept Development

Concept 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 Scheduling

If 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

Task

Activity

Hours

Date

1

Download the assignment

2

 

2

Concept development

5

 

3

Planning and scheduling

3

 

4

Requirements definition

5

 

5

Functional and detail design

10

 

6

Programming

45

 

7

Software integration and testing

10

 

8

Installation and acceptance

5

 

9

Documentation

10

 

10

Packaging and submission

3

 

11

Software maintenance

2

 

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 Definition

The 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):

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, acronyms, and abbreviations

1.4 References

1.5 Overview

2. Overall description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 Constraints

2.5 Assumptions and dependencies

3. Specific requirements

3.1 Functionality

3.2 Usability

3.3 Interfaces

3.3.1 User interfaces

3.3.2 Hardware interfaces

3.3.3 Software interfaces

3.3.4 Communications interfaces

3.4 Reliability

3.5 Security

3.6 Maintainability

3.7 Performance

3.8 Portability

3.9 Performance

3.10 Design constraints

3.11 User documentation and help system

4. Supporting information

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 Design

The 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 Design

The 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:

1. Overview

1.1. Purpose

1.2 Scope

2. References

3. Definitions

4. Description of IEEE standard 1016-1993

5. Design description organization

5.1 Design views

5.2 Recommended design views

5.3 Design description media

6. Considerations

6.1 Selecting representative design methods

6.2 Representative design method descriptions

6.3 Design document sections

6.4 Method-oriented design documents

7. Design methods

7.1 Function-oriented design methods

7.2 Data-oriented design methods

7.3 Real-time control-oriented design methods

7.4 Object-oriented design methods

7.5 Formal language-oriented design methods

8. Bibliography

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.

Programming

Write 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.

Testing

Submitting 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:

1. Scope and references

1.1 Inside the scope

1.2 Outside the scope

1.3 References

2. Definitions

3. Unit testing activities

3.1 Plan the general approach, resources, and schedule

3.2 Determine features to be tested

3.3 Refine the general plan

3.4 Design the set of tests

3.5 Implement the refined plan and design

3.6 Carry out the test procedures

3.7 Check for termination

3.8 Evaluate the test effort and unit

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 Acceptance

You 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.

Documentation

You 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.

graphics/note_icon.gif

The README.TXT file goes in the root or installation directory. Don't place it any where else.


Javadoc Comments

If 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
graphics/caution_icon.gif

It is an automatic failure if you do not specify how to start your application from the command line.


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"):

  • The exact Java Development Kit (SDK) version you used, including the platform you worked on. You can get this information by using the java -version command.

    In my case, this command returned the following:

     java version "1.4.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21) Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode) 
  • Explain how to run the program. You must provide exact command-line instructions. If any environmental setup is required, do not just say what needs to be done; include instructions on how to perform the setup. For example, do not say something like "Add server.jar to your classpath." You should document exactly how to add the JAR file to the classpath. Note: Your program must run correctly, no matter what directory it is installed in.

  • The location of your database file (for example, db.db).

  • The location of your design choices document (for more detail, see Chapter 5, "Documentation and Javadoc Comments").

  • The names of the files you have submitted, a note specifying their location in the directory structure, and a general description of each one's purpose.

User Help

Although 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:

  • Interface text Describe the labels on interface elements, such as menu items, fields, and buttons .

  • Application messages Explain any popup, status, or error messages.

  • Tutorial Include a small tutorial explaining the steps needed to use the application.

Design Choices Document

You 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:

  • Assumptions about your design, such as expecting the database file to be accessed by one client in local mode

  • How you handled deprecated methods

  • How you implemented specific methods (for example, must expand the search capability)

  • Database-locking mechanism

  • Client/server architecture

  • GUI information, such as how you implemented the table model for JTable (a required component)

  • Your approach to error and exception handling

  • How your application manages threads

Packaging and Submission

Your 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:

  • Full source and object code, including new classes, modified versions of supplied classes, and copies of supplied classes that were not modified. These classes should be in an appropriate directory structure along with the class files. You can use JAR files to contain groups of elements in your project submission, as you deem appropriatefor example, to support the running of your programs.

  • The original database file db.db. You should make a backup copy of all files that you downloaded, but especially this one.

  • You must provide HTML/javadoc documentation for all classes, whether supplied, modified, or new. You don't have to touch the comments on classes you downloaded unless you modified them.

  • You must provide user documentation for the database server and the GUI client. Sun does allow you to place the user documentation online. If you do that, you must supply the URL in the README.TXT file.

  • You must include a single text file called README.TXT.

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:

  • suncertify.server

  • suncertify.database

  • suncertify.client

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 Maintenance

On 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.

graphics/note_icon.gif

If you have failed the exam and want to resubmit your project for another attempt, you need to call Sun to purchase a resubmission option for your exam. The cost is generally one half the original amount.




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