Index Changes
Page Difference

Difference between version and version     

Back to Cross Product Features One Pager, or Cross Product Features One Pager Info


At line 48 changed 2 lines.
hardware products. Some examples of this is the Sun Access Manager and
the Cascade Service Gateway.
hardware products.
At line 57 removed 135 lines.
Two core requesters have pushed for this project. SUN Product Management
has requested the integration and interoperability solutions. Internal
architects have requested solutions to the systemic qualities.
#ifndef HALF_PAGER // A Half Pager stops at this point
4. Technical Description:
4.1. Details:
// To the extent known, how is this going to be done?
// If the source of implementation technology is external to Sun,
// identify them here, too.
// This information is used by the CPT's to get a feel for the
// complexity and risk involved, and by the ARC's to help understand
// the architectural constraints that this project is working
// under. Try to present alternatives and show relationships to
// existing or proposed projects/standards.
4.2. Bug/RFE Number(s):
// List any bug/rfe's which will be addressed by this proposed
// change.
4.3. In Scope:
// Aspects that are in scope of this proposal if not obvious from
// the above.
4.4. Out of Scope:
// Related aspects that are out of scope for this proposal if not
// obvious from the above.
4.5. Interfaces:
// What interfaces are introduced, modified or deleted by this
// proposal? What interfaces does it import and export? What are
// the new exported interface's stability levels?
// See http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp
// (Think of Files/directories, Ports, DTD/Schema, admin tools and
// config files, APIs, CLIs, etc, as well as incompatible or
// unexpected changes that may affect consumers and/or customers)
4.6. Doc Impact:
// List any Documentation (man pages, manuals, service guides...)
// that will be impacted by this proposal.
4.7. Admin/Config Impact:
// How will this change impact the administration of the product?
// Identify changes to GUIs, CLI, agents, plugins...
4.8. HA Impact:
// What new requirements does this proposal place on the High
// Availability or Clustering aspects of the component?
4.9. I18N/L10N Impact:
// Does this proposal impact internationalization or
// localization?
4.10. Packaging & Delivery:
// What packages, clusters or metaclusters does this proposal
// impact? What is its impact on install/upgrade?
4.11. Security Impact:
// How does this proposal interact with security-related APIs
// or interfaces? Does it rely on any Java policy or platform
// user/permissions implication? If the feature exposes any
// new ports, listeners, or any similar communication points
// which may have security implications, note these here.
4.12. Dependencies:
// List all dependencies that this proposal has on other
// proposals, components or products. Include interface
// specifics above in the interfaces section; list component
// version requirements here.
5. Reference Documents:
// List of related documents, if any (BugID's, RFP's, papers).
// Explain how/where to obtain the documents, and what each
// contains, not just their titles. Identify any related projects
// (by ID or case number, if possible).
6. Resources and Schedule:
6.1. Projected Availability:
// Dates in appropriate precision (quarters, years)
6.2. Cost of Effort:
// Order of magnitude people and time for the *whole* project, not
// just the development engineering part.
// You may wish to split the estimate between feature
// implementation, implementing adminsitrative Interfaces, unit
// tests, documentation, support training material, i18n, etc.
6.3. Cost of Capital Resources:
// Order of magnitude.
6.4. Product Approval Committee requested information:
6.4.1. Consolidation or Component Name:
6.4.3. Type of CPT Review and Approval expected:
// Pick one of
// Standard
// FastTrack
// BugFix or RFE
6.4.4. Project Boundary Conditions:
// Give the document's URL http://....
6.4.5. Is this a necessary project for OEM agreements:
// if Yes, give references
6.4.6. Notes:
// See dependencies section above.
6.4.7. Target RTI Date/Release:
// List target release & build and/or date.
// RTI = Request to Integrate - when does *this* project
// expect to be ready to integrate its changes back into
// the master source tree? We are not asking when the
// component wants to ship, but instead, when the
// gatekeeper/PM needs to expect your changes to show up.
// examples: S8u7_1, S9_45, Aug 2002...
6.4.8. Target Code Design Review Date:
6.4.9. Update approval addition:
// Did this project have prior Solaris PAC approval for a
// Marketing Release and now your requesting to go into an
// Update Release or Early Access CD?
6.5. ARC review type:
// Pick one of
// Standard
// FastTrack
// SelfReview
7. Prototype Availability:
7.1. Prototype Availability:
// Functional subset expected to be needed to leave "prototype"
// stage.
7.2. Prototype Cost:
// Subset of Cost of Effort to leave "prototype" stage.
#endif
G'day, Anonymous Guest

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-7) was last changed on 01-Oct-07 11:30 AM, -0700 by MarkWhite