Index Changes

Difference between version and version     

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

At line 1 changed 1 line.
Cross Product Features One Pager
At line 3 changed 3 lines.
This information is
Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know
Copyright 2007 Sun Microsystems
Cross Product Features
At line 20 removed 11 lines.
1.4. Name of Major Document Customer(s)/Consumer(s):
1.4.1. The PAC or CPT you expect to review your project:
// This should match the spelling used in PLCtool, as this will be
// used to cross-reference the information
1.4.2. The ARC(s) you expect to review your project:
// Leave blank if you don't have any preference
// This item is advisory only
1.4.3. The Director/VP who is "Sponsoring" this project:
// John.Doe@Sun.Com
1.4.4. The name of your business unit:
// SSG, Software, ...
At line 32 removed 6 lines.
1.5. Email Aliases:
1.5.1. Responsible Manager:
1.5.2. Responsible Engineer:
1.5.3. Marketing Manager:
1.5.4. Interest List:
At line 67 changed 2 lines.
hardware products. Some examples of this is the Sun Access Manager and
the Cascade Service Gateway.
hardware products.
At line 76 changed 157 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.
3.3. Business Justification:
// Why is it important or valuable to do this project?
// Include monetary estimate and precision.
3.4. Competitive Analysis:
// Who are the current and anticipated players in this market?
// How/why will we succeed when competing with them?
3.5. Opportunity Window/Exposure:
// Time-to-market window, if any, and precision.
3.6. How will you know when you are done?:
// What will you measure to determine that the project is complete?
// This section is for explicit measurable customer CTQs that apply
// to this specific feature proposal, not to the product as a whole.
// We *expect* every development team to meet their Feature,
// Performance and Security and Testing goals, as well as getting
// all required ARC and PAC review approvals, so don't put that
// sort of metric here.
#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.

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