Versions Compared

Old Version 10

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Benjamin Cheung

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

PROPOSAL - following feedback from the ONAP TSC 2019-02-07 the POC definition for Dublin


Proof of concept

POC DEFINTION:

Proof of concept (PoC) is a realization of a certain method or idea in order to demonstrate its feasibility,[1] or a demonstration in principle with the aim of verifying that some concept or theory has practical potential.[citation needed] A  A proof of concept is usually small and may or may not be complete.

The following are guidelines for a POC:

...

(source: Wikipedia)


POC GUIDELINES:

  1. SPONSOR - Every POC shall have a named sponsor for the feature whom acts as spokesperson at all checkpoints/meetings.
  2. NON BLOCKING - POC (only) related defects cannot shall not block the current release and not create any backward incompatibility
  3. COMPLIANCE - POC should be fully compliant with ONAP development guidelines, including development procedures.
    1. License/Vulnerabilities - POC development that includes entry points in the release version must comply with license scans and vulnerability fixes.
    2. Proprietary Components - PoC may include proprietary software or 3rd party software. It should be explicitly stated that the PoC is not contributing its software otherwise it is subject to CLAs. Note: The 3rd party software should comply with security guidelines otherwise there could be a backdoor vulnerability into ONAP.
    3. Security - PoC development shall be compliant to security guidelines and incorporate the latest security fixes so as not to create a security vulnerability.
    4. Performance - PoC should not impact the performance of the main code; this should be implied as it is kept in a separate Repo. The PoC development team should have an eye on ONAP performance if in the future it might be evolved to be incorporated into the ONAP platform.
    5. Back Doors - A POC should not introduce a back-door to the stable features so it must comply with security, code coverage, and license scans requirements
  4. POC features that are visible/accessible in the final product should be documented with limitations and POC status stated
  5. A use case POC
    1. .
    2. Resources - The PoC should perform an assessment to see that adequate resources are available such as PoC toolchains (Jenkins, Sonar, NexusID, LF resources, Test coverage resources etc).
    3. Approval for inclusion - The TSC or Use Case S/C shall approve the PoC to proceed as part of the current release.
  6. INDEPENDENT OF MAIN RELEASE - PoC are not part of the (current) ONAP release product.
    1. Documentation - The PoC may have documentation in a wiki developed by the community; but will not be incorporated into the official release documentation.
    2. Independence - The PoC shall be kept independent of the official (current) release. The PoC shall not introduce any new requirements in the current release.
    3. Integration/Testing responsibility - There is no responsibility from the integration or test teams to test the PoC S/W. The testing, integration and use of the PoC shall be in the purview of the PoC development team.
    4. PoC Release Notes - PoC release notes may be developed by the PoC team, they may include details of functionality available, known issues, and known limitations/incomplete features to keep of track development issues as they arise and serve as a communication vehicle for those evolving the PoC in the future.
  7. CODE INDEPENDENCE - The PoC software shall be kept separate and independent of the main ONAP branch/repository.
    1. Common Code Usage - PoC software using common code, does not change the treatment of the common code with regards to completeness, S3P, documentation and other common code expectations
    2. Otherwise, POC should be kept in separate repo branch.
    3. Separate Branch - PoC should be kept in separate repository branch. There should not be PoC S/W introduced into the main ONAP software branch. This prevents complications in testing and integration of the ONAP software in the main branch. The PoC should not modify any existing (current release) core ONAP components.
    4. Evolutionary Platform Software - EXCEPTION CASE: Under the blessing of a PTL for the platform component, there might be a situation where a PoC is demonstrating something to evolve the Platform component (e.g. SO, VID, VNF-SDK etc) and some of the PoC software may be included with in the CURRENT release. Experience has shown that it was important to merge PoC code in the current release to make the task manageable. Note: it is expect this would be most useful in large, multi-release PoCs.
  8. PROCESS - The PoC may follow a process during development.
    1. Milestones - The PoC team may follow some sort of development process. It is suggested that they use the Mx milestones/gates as the release progresses or some similar process. Note: it is expected that using a process would facilitate formal inclusion of the PoC in the subsequent ONAP release(s).
    2. Final Approval - The final approval of a PoC shall ultimately be determined by the sponsor/leader of the PoC (see Point #1). It is suggested that a "report" of how the PoC went to socialize and inform the TSC or other relevant teams.
    3. PoC Overlap - It is recommended that the PoC team socialize their PoC so that other teams working on Use cases and PoCs are aware of potential cross-interactions that might occur and overlap in scope and functionality.
  9. SCOPE - A PoC can be used to demonstrate functionality related to a project concept, a Use Case, functional or non-functional requirements, project specific extensions.
    1. Definition - It is the responsibility of the PoC team to define the scope and extent of the PoC. 
    2. Project Review - the PoC team shall review the PoC with impacted sub-committees (such a security and modeling S/C) and projects PTLs (such as A&AI and SDC).
  10. POC INCORPORATION - The point of a PoC is to demonstrate something (hopefully) useful. PoCs teams that wish to incorporate the PoC code into the main repository should follow the standard procedures for introducing new functionality and use cases in subsequent ONAP releases
    1. Feature Proposals - There exists a standard procedure new functionality introduction leading up to M0 shall be followed by a PoC in subsequent releases by the PoC team if they wish to incorporate PoC Software into the main repository.
    2. Partial PoC Introduction - The original PoC scope may be altered from what is introduced in a future release. An ideal case might be that a PoC software might serve as seed code, but it does not have to. Lessons learned can guide what would get incorporated or proposed in the future release.
    3. Merge Responsibility - It will be the responsibility of the PoC Team to properly merge the PoC code into the main-line branch (S/W repo) if it becomes part of the future release. Merging should follow compliance principles (described in point #3 above).
    4. Proprietary Components - If the PoC used proprietary components or software, for formal including into ONAP it would need to be excluded in the final merge because ONAP is an open source initiative. Note: A PoC using proprietary components are "on" or "with" ONAP; a contributed PoC (without proprietary components) are said to be "in" ONAP.



==-=-=-=-=-=-=-=-=-=-=-CUT LINE, Previous content preserved for continuity... Delete after TSC review-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


POC is equivalent to "Tech Preview" or "Experimental"

...