Versions Compared

Old Version 10

changes.mady.by.user user-8fc39

Saved on

compared with

New Version 11

changes.mady.by.user Benjamin Cheung

Saved on

Key

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

...

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 proof of concept is usually small and may or may not be complete.


The following are guidelines for a POC GUIDELINES:

  1. SPONSOR - Every POC has 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 release
  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. Security - PoC development shall be compliant to security guidelines and incorporate the latest security fixes
    3. 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.
    4. 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. INDEPENDENT OF MAIN RELEASE - POC features that are visible/accessible in the final product should be documented with limitations and POC status statedare not part of the 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 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.
  5. CODE INDEPENDENCE - The PoC software shall be kept separate and independent of the main ONAP branch/repository.
    1. Common Code Usage - POC software
    A use case POC
    1. 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, Separate Branch - POC should be kept in separate repo branchrepository 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.
  6. 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. 
  7. 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.



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

...