This file is a template that you can use for your TCK planning.
This template uses colors and fonts as follows:
A TCK project plan provides a comprehensive description of the TCK as a product.
This TCK Project Plan Template is based on IEEE project planning standards and Sun's "TCK Project Planning and Development Guide." We assume that you are consulting that guide as you work through the template. The "TCK Project Planning and Development Guide" can be obtained from the Java Community Process (JCP) web site at: jcp.org/resources/tdk.
JSR Naming Program. One of the requirements for TCKs being developed under the JSR Naming Program is submission of a TCK Project Plan to the JSR Naming Coordinator. A template for this JSR-required plan is available on the JSR Naming Program web site at: java.sun.com/programs/jsr-naming. Or you can use this template for the plan you submit to the JSR Naming Program.
Date |
Author |
Version |
Comments |
|
|
|
|
|
|
|
|
This plan contains the following sections:
Provide a brief (one or two paragraph), high-level description of the specification.
If an existing specification is being changed, describe the changes, particularly those that affect the TCK.
If this is a new specification based on a previous one, identify the previous specification by name, JSR-number, and the URL where it can be located.
Provide a brief (one or two paragraph), high-level description of the TCK.
See "TCK Project Planning and Development Guide" for a list of questions this section of your Project Plan should address.
If an existing TCK is being updated or revised, identify the previous TCK and describe the planned changes. For example, you may be updating the TCK to accommodate changes in the specification, or the TCK is being upgraded to a new version of the test harness, or you are implementing bug fixes, or providing an improved configuration, or providing support for additional J2ME configurations and profiles, etc.
List the specific new features and bug fixes. If appropriate, identify the relevant bug or RFE number.
Describe the assumptions on which the project is based, and any constraints being imposed. For example:
List the TCK-related deliverables that you intend to provide:
The TCK developed to test implementations of specification_name will include:
read_me
file or bothThe additional deliverables listed below are for TCKs created under the JSR Naming Program. If your specification uses the Java trademark-"Java? Braille API Specification," for example-you MUST comply with the requirements of the JSR Naming Program and include the deliverables listed below. If your specification does not use the Java name as a trademark-"Braille API Specification, for the Java Platform," for example-compliance with JSR Naming Program requirements is optional.
The following deliverables will be provided to meet the requirements of the JSR Naming Program:
.assert
file), both preliminary
and finalIf some normally-required TCK component is not being included in the deliverables list, identify it and explain why it is not necessary in this case. If all expected components are being delivered, you can omit this section or simply enter "Not Applicable."
Provide a high-level summary of initial target dates for the major JCP milestones, JSR Naming Program required deliverables (if any), and any other major milestones you wish to include.
(The example shown in Table 2 below assumes that your TCK is being developed to meet JSR Naming Program requirements. It also assumes that your project planning process does not get underway until after the specification has been submitted for Community Review. The stages before Community Review are listed below for your information and for cases where you might wish to include them in the plan, or for situations where they have yet to be completed and need to be factored into the schedule.)
Deliverable or Milestone | Date Completed |
---|---|
Initiate JSR process by submitting a Proposal Form to the JCP PMO | |
Begin license process with Sun for JSR Naming Program | |
JSR Naming Program License signed by Sun | |
Submission of this project plan to JSR Naming Coordinator | |
Complete first draft of specification | |
Submit draft specification to PMO for Community Review | |
Target Date | |
Mark up specification | |
Submit preliminary assertion list (.assert file) to JSR Naming Coordinator | |
Start TCK development | |
Internal milestone 1. (For example complete Alpha version of TCK and RI.) | |
Internal milestone 2. (For example complete Beta version of TCK and RI.) | |
Submit preliminary deliverables to JSR Naming Coordinator. | |
Complete development of TCK (including documentation). | |
Submit final specification draft to PMO for Public Review. | |
Submit final deliverables to JSR Naming Coordinator. | |
Submit completed JSR Naming Program Questionnaire. | |
Notify JCP Project Management Office (PMO) of approval. | |
Make final specification and all materials available. |
Every project needs a detailed schedule that is maintained on an ongoing basis and frequently updated. The normal practice is to use a project management tool or spreadsheet for this purpose.
The detailed schedule needs to be available online to all team members (via a web site, for example). A pointer to the location of the detailed schedule needs to be entered here in this plan.
Two kinds of information need to be tracked:
For each task identified in the schedule you need to provide appropriate information. For example:
As appropriate for your project, provide a summary budget estimate of what it will cost to complete TCK development. For example:
See the "TCK Project Planning and Development Guide" for useful tips on how to estimate personnel requirements for TCK development.
Identify your project roles and responsibilities. Maintain this section on an ongoing basis, by filling in names and contact information as it becomes available. Table 3 provides an example Personnel Table.
Role | Responsibility | Name | Phone | |
---|---|---|---|---|
Engineering Project Manager | Provide resources and project approval | |||
Program Manager | Manage project schedule | |||
Architect/Developer | Design and coding | |||
SQE Engineer | Develop QA tests | |||
Writer | Create User's Guide | |||
SQA Engineer | Qualify build releases | |||
Release Engineering | Manage build process |
If appropriate, identify the current members of the Expert Group responsible for developing the specification that the TCK is intended to test. Keep this part of the plan up-to-date as it evolves over time. Table 4 provides an example Expert Group table.
The current members of the specification's Expert Group are:
Company | Name | Phone | |
---|---|---|---|
If multiple companies or organizations are involved in the project, describe how tasks and responsibilities will be distributed among them, and summarize the resources (personnel, time, material, infrastructure) that each organization is expected to allocate to this project.
Describe how the project team will communicate internally and externally. As appropriate for your project, provide information about such things as aliases, web sites, meeting schedules, distribution of meeting minutes, project reviews, status reporting, and other well-defined communication mechanisms. This section of the plan should provide readers with the information they need to fully participate in the project.
Define and describe the major internal milestones, and the acceptance criteria for each milestone.
The example below uses "Alpha," "Beta," and "FCS" as example major milestones, but your team may use a different system of milestones. The milestones and acceptance criteria shown below are examples based on the JSR-Naming program and should not be considered as requirements for projects not conforming to JSR-Naming requirements.
Alpha Release acceptance criteria:
Beta Release acceptance criteria:
Final product acceptance criteria:
Note that TCKs developed under the JSR Naming Program must meet the program's minimum coverage standards by FCS.
List any dependencies on other specifications or anything you need from others, in order to be successful. For example, if you are depending on some other technology that has not yet been released, you would list that here.
Describe any issues or risks that may affect the project.
A preparation plan describes necessary preparations before TCK development work can begin.
See "TCK Project Planning and Development Guide" for a list of questions this section of your Project Plan should address.
A preparation plan might include sections such as the following:
If appropriate, describe what training (if any) will be proved to those working on the TCK development team before development begins. This might include formal training, working through the tutorials in guides and manuals, working with the Sample TCK provided by Sun as part of the Java Compatibility Java Compatibility Test Tools (Java CTT).
If appropriate, describe what preliminary research or prototyping (if any) will be needed before TCK development begins.
If appropriate, describe new facilities, equipment, or software tools (if any) that need to be acquired or set up in order to complete the project.
Describe how the TCK will be prepared for release, packaged, and provided to customers. For example, it might be packaged in a zip file and downloaded from a web site, in which case you would describe that including the name (or naming system) of the zip file and the URL of the web site.
The test design document describes what needs to be tested and how that is to be accomplished.
The common practice is to create and maintain the TCK Design Document as a separate document (in which case a pointer to its location should be included in the overall TCK Project Plan). However, you can combine it with other plans as you think appropriate.
The design document describes:
See "TCK Project Planning and Development Guide" for a more complete list of questions this section needs to address.
You may also wish to include the actual test case specifications that describe in logical terms what each test or test case does and the expected results.
These test-case specifications are typically provided to TCK users. Describe how that will be accomplished. For example, when the JavaTest harness, the recommended practice is to provide the individual test case specifications in HTML within the test suite test directory tree.
Describe the documentation that will be provided with your TCK.
The common practice is to create and maintain the Documentation Plan as a separate document (in which case a pointer to its location should be included in the overall TCK Project Plan). However, you can combine it with other plans as you think appropriate.
Your documentation plan should include content description, how the material will be provided to customers, and the formats you will provide (printed, PDF format files, web-based, etc).
A thorough TCK documentation plan usually covers the following topics:
See "TCK Project Planning and Development Guide" for a detailed list of questions this section of your Project Plan should address.
Some or all of the following documents are normally delivered with a TCK:
Describe how your TCK will be tested against your RI and the specification.
The common practice is to create and maintain the Quality Assurance Plan as a separate document (in which case a pointer to its location should be included in the overall TCK Project Plan). However, you can combine it with other plans as you think appropriate.
If appropriate, divide the plan into sections covering the test plan for your major delivery milestones (alpha, beta, FCS, etc).
Information on the following topics should be provided:
TCKs being developed under the JSR Naming Program need to include a QA analysis of coverage reports to see if coverage meets the program's minimum standards.
See "TCK Project Planning and Development Guide" for a list of questions this section of your Project Plan should address.
Test Specifications must contain enough detail to allow a competent test writer, who is familiar with the tool, to create the specified test cases and input data necessary to demonstrate the required behavior and to measure whether the tool "passes" or "fails."
The common practice is to create and maintain Test Specifications as a separate document (in which case a pointer to its location should be included in the overall TCK Project Plan). However, you can combine it with other plans as you think appropriate.
The Test Specifications can be found at: Location.
Each test specification must:
Describe how the TCK will be maintained and updated.
The common practice is to create and maintain the Maintenance Plan as a separate document (in which case a pointer to its location should be included in the overall TCK Project Plan). However, you can combine it with other plans as you think appropriate.
Include the following information:
Define any terms and acronyms used in this document that may be unfamiliar to typical readers. Table 5 provides an example Glossary Table.
Term or Acronym | Definition |
---|---|
Provide references to any other relevant documents as appropriate.
Version 1.2 May, 2003
Copyright © 2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Sun, Sun Microsystems, the Sun logo, Java and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Federal Acquisitions: Commercial Software - Government Users Subject to Standard License Terms and Conditions.
Copyright © 2003 Sun Microsystems, Inc. Tous droits reserves. Distribue par des licences qui en restreignent l'utilisation. Le logiciel detenu par des tiers, et qui comprend la technologie relative aux polices de caracteres, est protege par un copyright et licencie par des fournisseurs de Sun. Sun, Sun Microsystems, le logo Sun, Java et Solaris sont des marques de fabrique ou des marques deposees de Sun Microsystems, Inc. aux Etats-Unis et dans d'autres pays.
ing HTML relocated