This file is a template that you can use for your TCK planning.

This template uses colors and fonts as follows:

• Blue italic: Explanations of how the template should be used.

• Magenta italic: Variables that you need to replace with your specific information.

• Red: Optional material that you may, or may not, include in your TCK project plan. (If the section head is in red, the entire section is considered optional.)

TCK Project Plan
TCK_Name
Version X.X

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.

Project Plan Modification History

Table 1: Plan Modification History

Date	Author	Version	Comments

Table of Contents

This plan contains the following sections:

• Project Description.
  
• Overview.
  
• New Features.
  
• Assumptions and Constraints.
  
• Deliverables.
  
• Non-deliverables.
  
• Schedule.
  
• Budget Summary.
  
• Roles and Responsibilities.
  
• Communications and Reporting.
  
• Milestones and Acceptance Criteria.
  
• Dependencies.
  
• Risks, Issues and Responses.
  
• Start-Up/Preparation Plan.
  
• Deployment Plan.
  
• Test Design Document.
  
• TCK Documentation Plan.
  
• TCK Quality Assurance (QA) Plan.
  
• Test Specifications.
  
• TCK Maintenance Plan.
  
• Appendix A: Glossary.
  
• Appendix B: References.

Project Description

• Name of the specification: specification_name
  
• JSR number: JSR-NNN
  
• URL of the specification: http://jcp.org/jsr/detail/nnn.jsp
  
• URL of the TCK (if known):

Overview

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.

New Features

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.

Assumptions and Constraints

Describe the assumptions on which the project is based, and any constraints being imposed. For example:

• Final test coverage target goal (averaged across all tests):nn%
  
• Test harness to be used: (Note that JavaTest harness 3.x is required for JSR Naming Program.)
  
• Signature Test tool and signature file to be included in the TCK.
  
• Spec Trac Tool to be used to annotate assertions in the spec and track assertion coverage.
  
• API Coverage tool to be used to provide API coverage report.
  
• Other assumptions and constraints as needed.
  
• The Technology Compatibility Kit (TCK) described in this project plan will meet all of the TCK requirements identified by the JSR Naming Program.

Deliverables

List the TCK-related deliverables that you intend to provide:

The TCK developed to test implementations of specification_name will include:

• The TCK tests, test suite, and test framework including test harness
  
• Compatibility Rules for products developed under the specification_name
  
• Appeals Process for challenging TCK tests
  
• TCK User Guide
  
• Release Notes or read_me file or both
  
• Other documentation (if needed)
  
• Audit process
  
• Any additional TCK deliverables as needed.

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

• Completed Licensing Web form from the JSR Naming web site
  
• Completed license agreement (2 copies) (not needed for TCKs being developed by Sun)
  
• Spec Trac assertion list (.assert file), both preliminary and final
  
• JavaTest harness test run results, both preliminary and final
  
• Exclude List, both preliminary and final
  
• Spec Trac assertion coverage report, both preliminary and final
  
• API Coverage Tool coverage report, both preliminary and final
  
• Completed JSR Naming Program Completion Questionnaire
  
• This TCK Project Plan, and an updated version of this plan when the preliminary TCK and coverage reports are delivered

Non-deliverables

If 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."

Schedule

Schedule Summary

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

TABLE 2: Example Schedule Summary

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.

Detailed Schedule

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:

• Scheduled start and completion dates for project tasks are maintained in the spreadsheet or management tool.
  
• Descriptions of each scheduled task can be included in the management tool or spreadsheet itself, maintained in a separate document, or entered here in this plan.

For each task identified in the schedule you need to provide appropriate information. For example:

• Task name:
  
• Description:
  
• Owner (who's responsible):
  
• Dependencies (if any):
  
• Deliverables:
  
• Acceptance Criteria (if appropriate):
  
• Risks/Issues (if any):
  
• Resources:
  
• Estimated cost:
  

Budget Summary

As appropriate for your project, provide a summary budget estimate of what it will cost to complete TCK development. For example:

• Personnel: Describe needs.
  You may wish to break personnel needs into separate categories such as:
  • Management:
    
  • Engineering:
    
  • Documentation:
    
  • Support:
    
  • Estimated cost: font color=magenta>$nnn,nnn.
• Software and equipment: Describe needs.
  Software and equipment resources might include items such as:
  • New software: (for example, software tools)
    
  • Office space:
    
  • Lab space:
    
  • Supplies:
    
  • Estimated cost: $nnn,nnn.
    
• Other expenses (if needed): Describe needs.
  Other expenses might include items such as:
  • Support services:
    
  • Travel:
    
  • Teleconferencing:
    
  • Estimated cost: $nnn,nnn.
• Department overhead or charges (if applicable): Describe needs.
  Estimated cost: $nn,nnn.

  See the "TCK Project Planning and Development Guide" for useful tips on how to estimate personnel requirements for TCK development.

Roles and Responsibilities

Project Personnel

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.

TABLE 3: Example Project Personnel Table

Role	Responsibility	Name	Phone	Email
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

Expert Group Members

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:

TABLE 4: Example Expert Group Table.

Company	Name	Phone	Email

External Organizational Roles, Responsibilities, and Resources

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.

Communications and Reporting

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.

Milestones and Acceptance Criteria

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:

• Assertion coverage goals using the JSR Naming Program metric standards:
  • Percent of total assertions that are testable: nn%
    
  • Percent of testable assertions with at least one test (averaged across all packages): nn%
    
  • Percent of testable assertions with at least one test (per package): nn%
    
  • Percent of class members that are tested: nn%
    
  • Percent of class member signatures that are verified: nn%

• Total number of unresolved bugs: nn
  
  • Maximum number of unresolved High-Priority bugs: nn
    
  • Maximum number of unresolved Medium-Priority bugs: nn
    
  • Maximum number of unresolved Low-Priority bugs: nn

• JCP process status: (Explain where you are to be in the JCP timeline at this point.)

• Documentation status: (For example: being planned, work underway, draft available, completed.)
  • TCK User's Guide:
    
  • Release Notes:
    
  • Other:
    
• Functionality status: (For example, Framework complete, the test harness and TCK can be executed from the command line and run against the RI without crashing, though some tests and features may not be available.)
  

• Additional criteria as needed.

Beta Release acceptance criteria:

• Assertion coverage goals using the JSR Naming Program metric standards:
  • Percent of total assertions that are testable: nn%
    
  • Percent of testable assertions with at least one test (averaged across all packages): nn%
    
  • Percent of testable assertions with at least one test (per package): nn%
    
  • Percent of class members that are tested: nn%
    
  • Percent of class member signatures that are verified: nn%

• Total number of unresolved bugs: nn
  
  • Maximum number of unresolved High-Priority bugs: nn
    
  • Maximum number of unresolved Medium-Priority bugs: nn
    
  • Maximum number of unresolved Low-Priority bugs: nn

• JCP process status: (Explain where you are to be in the JCP timeline at this point.)
  

• Documentation status: (For example: being planned, work underway, draft available, completed.)
  • TCK User's Guide:
    
  • Release Notes:
    
  • Other:

• Functionality status: (For example, Tests complete, the test harness and TCK can be executed against the RI without crashing. All tests and features are available. Known High-Priority bugs are described in the Release Notes.)

• Additional criteria as needed.

Final product acceptance criteria:

Note that TCKs developed under the JSR Naming Program must meet the program's minimum coverage standards by FCS.

• Assertion coverage goals using the JSR Naming Program metric standards:
  • Percent of total assertions that are testable: nn%
    
  • Percent of testable assertions with at least one test (averaged across all packages): nn%
    
  • Percent of testable assertions with at least one test (per package): nn%
    
  • Percent of class members that are tested: nn%
    
  • Percent of class member signatures that are verified: nn%

• Total number of unresolved bugs: nn
  
  • Maximum number of unresolved High-Priority bugs: nn
    
  • Maximum number of unresolved Medium-Priority bugs: nn
    
  • Maximum number of unresolved Low-Priority bugs: nn

• JCP process status: (Explain where you are to be in the JCP timeline at this point.)
  

• Documentation status: (For example: being planned, work underway, draft available, completed.)
  • TCK User's Guide:
    
  • Release Notes:
    
  • Other:

• Functionality status: All features and tests fully functional. All known limitations described in the Release Notes.

• Additional criteria as needed.

Dependencies

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.

Risks, Issues and Responses

Describe any issues or risks that may affect the project.

Start-Up/Preparation Plan

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:

Training

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

Research and Prototyping

If appropriate, describe what preliminary research or prototyping (if any) will be needed before TCK development begins.

Facilities and Equipment

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.

Deployment Plan

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.

Test Design Document

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:

• Which specification assertions need to be tested?
  
• Issues that must be addressed due to a special TCK-related hardware or software characteristics.
  
• Test agent if needed.
  
• Application manager if needed.
  
• Kinds of tests needed (class, API functionality, etc.)
  
• How will test results be verified?
  
• Will any standard test-library code be needed?
  
• Test cases
  
• How the individual test cases are combined into tests
  
• How the tests are incorporated into the test suite
  
• How the test suite is integrated with test harness
  
• JavaTest harness configuration interview
  
• The test framework and its components. The framework might (or might not) include components such as Java Application Manager (JAM) or Application Management Software (AMS), test agent, test finder, test script, and so forth. A test framework might also include user- supplied software components (plug-ins).

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.

TCK Documentation Plan

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:

• Overview and description of the document set (for example, User's Guide and Release Notes.
  
• Delivery formats for each deliverable (for example, ink-on-paper, web, PDF, etc.
  
• Documentation personnel and assignments
  
• Documentation schedule and priorities
  
• Audiences for the different materials
  
• Information sources
  
• Reviewers (content, legal, trademark)
  
• Copy-editing
  
• Documentation risks and issues
  
• Chapter outline of User's Guide

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:

• TCK User's Guide.
  A good TCK User's Guide should provide an overview of the TCK and compatibility testing, installation information, configuration and setup information, instructions on how to use the TCK, information on software components that the user has to provide, debugging and problem-solving information, and reference information.

• Test harness documentation.
  (Note that if you are using the JavaTest harness its documentation is normally provided by Sun and simply given to your customers as part of the TCK bundle.)

• Release notes or README file.

• Web site content (if applicable).

• Other documentation if needed.

TCK Quality Assurance (QA) Plan

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:

• Overview of how is testing the TCK to be accomplished.
  
• Test environment to be used for testing the TCK.
  
• How many builds, or which builds, are to be tested.
  
• The platforms to be tested.
  
• QA pass/fail criteria.
  
• How problems and bugs will be reported, tracked, and corrected?
  
• Elements to be tested:
  The elements to be tested needed to be described in detail. For example, the following elements might be tested:
  • System as an entire entity
    
  • Individual components
    
  • Generation of correct error messages
    
  • JavaTest harness integration
    
  • Signature test
    
  • TCK configuration options
    
  • TCK installation procedures
    
  • TCK user guide and other documentation

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

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:

• Clearly identify the behavior to be tested. Test case success must be clearly specified. Note that several different test cases could be specified for each behavior.

• Define individual test cases with each identified by a unique ID.

• If predetermined inputs and outputs/results are needed to describe the tests, the input data can be identified separately and referenced by the relevant test cases.

TCK Maintenance Plan

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:

• Name of Maintenance Lead:

• Maintenance updates:
  Describe how Maintenance updates to the TCK will be provided to customers.

• Test challenges.
  Provide a summary overview of how test challenges will be received, who will respond to them, and how the appeals process will be handled.

• Exclude Lists:
  Describe how customers will be informed of tests that do not have to be run because of a successful test appeal or some other problem. (The JavaTest harness uses an Exclude List for this purpose. Other test harnesses may use a different mechanism.)

Appendix A: Glossary

Define any terms and acronyms used in this document that may be unfamiliar to typical readers. Table 5 provides an example Glossary Table.

TABLE 5: Example Glossary Table

Term or Acronym	Definition

References

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