User Tools

Site Tools


requirements_projects

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
requirements_projects [2015/08/10 19:36]
Ildiko Vancsa [Project lifecycle]
requirements_projects [2015/08/11 13:53] (current)
Ildiko Vancsa [Project lifecycle]
Line 31: Line 31:
 ==== Project lifecycle ==== ==== Project lifecycle ====
  
-High level project lifecycle for the current categories:+High level (sub-)project lifecycle for the current categories:
  
 {{  :​requirements_projects:​project_lifecycle_doc_image.png?​600 ​ |}} {{  :​requirements_projects:​project_lifecycle_doc_image.png?​600 ​ |}}
  
-As you can see on the above figure the steps for each current category are the same, on high level the above mentioned categorization does not add any differentiation.+As you can see on the above figure the steps for each current category are the same, on high level the above mentioned categorization does not add any differentiation ​in the meaning of how we are using these terms. On the other hand today we are not following the process of having sub-projects for the different types of activities, but we are more aiming for covering all these under the umbrella of one single project.
  
 The categorization does not define anything about the lifecycle of the projects contained by each group either. In case of each and every project we have phases as: The categorization does not define anything about the lifecycle of the projects contained by each group either. In case of each and every project we have phases as:
Line 52: Line 52:
 Requirements can target deployment, testing of the platform or gaps in upstream projects. It is the responsibility of the project to cover the implementation,​ testing and documentation in the appropriate repository (repositories). Requirements can target deployment, testing of the platform or gaps in upstream projects. It is the responsibility of the project to cover the implementation,​ testing and documentation in the appropriate repository (repositories).
  
-By removing categorization we would like to encourage projects to follow the Agile flow. Having only generic projects we also remove the need of an additional administration step, which was required for Requirements Projects to move into the Collaborative Development category. ​The lifecycle of projects in each release looks like the follwoing:+By removing categorization we would like to encourage projects to follow the Agile flow. Having only generic projects we also remove the need of an additional administration step, which was required for Requirements Projects to move into the Collaborative Development category.
  
-{{  ​:requirements_projects:​project_lifecycle.jpeg?​600 ​ |}}+The lifecycle process without categories looks like the following:
  
 +{{  :​requirements_projects:​project_lifecycle.jpeg?​900 ​ |}}
 +
 +We haven'​t followed the lifecycle process depicted on the above figure during the Arno release. It is still an open question of how to handle these stages currently identified for a project and also whether we need all the steps. It is also a question whether we should aim more for a Big Tent-like structure rather than strict review processes.
 ===== Requirements Projects ===== ===== Requirements Projects =====
  
Line 177: Line 180:
    * Is there a finished/​victory state?    * Is there a finished/​victory state?
    * Should requirements projects maintain links to their upstream project dependencies?​    * Should requirements projects maintain links to their upstream project dependencies?​
 +     * Yes, pointers to top level items, from which the sub-items can be identified
    * Is there a comparison to specific differences from existing process?    * Is there a comparison to specific differences from existing process?
      * Not more than the retrospective above      * Not more than the retrospective above
    * Are we treating Collaboration & Development projects as Requirements Project?    * Are we treating Collaboration & Development projects as Requirements Project?
 +     * We are handling each project as generic open source projects
    * Requirements was considered as Carrier input and not Gaps with respect to Upstream Projects and thus the suggested end-to-end pipeline brings the risk of Collaboration & Development projects outside driving the agenda rather than NFV reference architecture    * Requirements was considered as Carrier input and not Gaps with respect to Upstream Projects and thus the suggested end-to-end pipeline brings the risk of Collaboration & Development projects outside driving the agenda rather than NFV reference architecture
 +     * This brings in more the question of who and how should supervise of the project artifacts
    * This means that scope of OPNFV being aligned with NFV reference architecture will need an Architecture Review Board(ARB) to ensure that Collaboration and Development Projects as well all Requirement project keep alignment with NFV reference architecture    * This means that scope of OPNFV being aligned with NFV reference architecture will need an Architecture Review Board(ARB) to ensure that Collaboration and Development Projects as well all Requirement project keep alignment with NFV reference architecture
  
requirements_projects.1439235401.txt.gz ยท Last modified: 2015/08/10 19:36 by Ildiko Vancsa