Differences

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

--- requirements_projects [2015/07/31 16:56]
Ildiko Vancsa [Project life cycle]
+++ requirements_projects [2015/08/11 13:53] (current)
Ildiko Vancsa [Project lifecycle]
@@ Line 1: / Line 1: @@
-====== OPNFV projects ======
+====== OPNFV program ======
+===== Clarification of terms =====
+Using the PMI definition, the traditional interpretation of **project** is: "It's a temporary endeavor undertaken to create a unique product, service or result. A project is //temporary// in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is //unique// in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal."
+After defining project, we can say that **program** is a group of related projects being managed together.
+As OPNFV is an open source community the term //project// gets a slightly different interpretation. The difference comes from not defining explicitly the end time, but focusing on the //joint development effort on a specific product//. This product is built, maintained and improved by the community of developers and it can have many releases.
+In this sense the **OPNFV program** consists of several **open source projects**, the set of projects may vary among releases.
+===== OPNFV projects =====
 The activities of OPNFV are organized into several projects, which are targeting different areas with different focus points. The projects are working in collaboration to cover the integration points between the areas and on platform level.
-===== Labelling =====
+==== Labelling ====
 As OPNFV is a mid-stream community we have to cover an end to end process. This means that we have to identify what is missing from the upstream projects we are using, we need to address those gaps. In parallel we are also working on integrating these open source components and then validating and verifying the platform we got.
@@ Line 17: / Line 29: @@
 These categories mean more a labelling to see on which part of the end to end flow the projects are active.
-===== Project life cycle =====
+==== Project lifecycle ====
-The above mentioned categorization does not define anything about the life cycle of the projects contained by each group. In case of each and every project we have phases as:
+High level (sub-)project lifecycle for the current categories:
+{{  :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 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:
    * Requirement definition
@@ Line 28: / Line 46: @@
 As we are working in an **Agile environment** these phases are **not parts of a waterfall way of working**! This means that the requirements specification phase does not have to be completed before starting the implementation of one or more items on the list.
-Basic Agile flow:
+**Basic Agile flow:**
 {{ :requirements_projects:sdlc_-_software_development_life_cycle.jpg?300 |}}
@@ Line 34: / 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).
-High level project life cycle for the current categories:
+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_doc_image.png?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 =====
@@ Line 159: / Line 180: @@
    * Is there a finished/victory state?
    * 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?
      * Not more than the retrospective above
    * 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
+     * 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

Wiki

User Tools

Site Tools

Differences

Page Tools