Thanks Alla and Yoav to put it together. Since Integration team will make
automatic CI/CD far before the real release, I suggest that they get involved
asap: the more they understand the use case, the more they could develop the
testing cases. And most importantly they define the gating use case.
I suggest to make some minor adjust on the flow:
1. Use case subcommittee discuses new use cases
2. Use case subcommittee produces use case flow diagrams, ONAP flow
diagrams, and suggests potential PNFs / VNFs
3. Use case subcommittee gets feedback from the potentially effected
projects including integration team on feasibility
4. Iterate back to 2.
5. TSC approval
6. Architecture subcommittee defines the general new/modified
interfaces principles, based on approved use cases
7. Projects define their extended functionality and their external
APIs, following those principles.
8. Detailed per-component flows are defined and projects write their
user stories / implement them; Integration team will work with use case
subcommittee continues to accompany the use case development, review epics/user
stories, answer questions, etc. (behave as system engineers for the use case)
through test start date.
9. Integration team will define the gating use case based on step 8; and
finalize the PNFs / VNFs selection, with the help of use case subcommittee,
architecture subcommittee, PTLs with ONAP projects
10. TSC approval the gating use case.
11. Integration project leads (coordinates) effort to get the gating
use case tested, repaired, and verified, and the results will be documented.
Regards,
Helen Chen
On 6/19/17, 11:39 AM, "[email protected] on behalf of Alla
Goldner" <[email protected] on behalf of
[email protected]> wrote:
Hi Yoav, Oliver, Steve, all,
Firstly, I believe we need to distinguish R1 from any future release. The
methodology we build here would be good to work with in the future releases,
but not immediately.
For our immediate R1 work we need to quickly start interaction between the
use cases teams, the integration team and the projects, making sure all these
are aligned.
For the longer term activities, I would say, following Yoav's description
below and the other received comments, we may consider the following split:
1. Use case subcommittee discuses new use cases
2. Use case subcommittee produces use case flow diagrams and ONAP
flow diagrams
3. Use case subcommittee gets feedback from the potentially effected
projects including integration team on feasibility
4. Iterate back to 2.
5. TSC approval
6. Architecture subcommittee defines the general new/modified
interfaces principles, based on approved use cases
7. Projects define their extended functionality and their
external APIs, following those principles.
8. Detailed per-component flows are defined and projects write
their user stories / implement them; Use case subcommittee continues to
accompany the use case development, review epics/user stories, answer
questions, etc. (behave as system engineers for the use case) through test
start date
9. Integration project leads (coordinates) effort to get the use
case tested, repaired, and verified
Best regards,
Alla Goldner
Open Network Division
Amdocs Technology
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Yoav Kluger
Sent: Monday, June 19, 2017 9:07 PM
To: Stephen Terrill <[email protected]>; SPATSCHECK, OLIVER
(OLIVER) <[email protected]>; [email protected]
Subject: Re: [onap-discuss] Use Case Subcommittee Flow
Hi,
The use case work involves two activities:
1. Define the use case, in particular the specifics of the use case
which should be proven for a given release.
2. Define ONAP delivery of the use case, i.e. ONAP flow diagrams
Activity 1 requires domain expertise in the specific area of the use case.
As an example, in the vCPE case we needed to know the base spec if one existed
- in our case it was TR-317, and related technologies. Then we needed to take
use case architectural decisions based on a) what elements from the spec we
want to define as deliverables for R1; b) what modifications are needed in
various components of the use case; c) take lower level decisions which the
spec leaves undefined but which must be taken in order for the use case to work
and make sense to its customers.
These expertise will typically reside in the use case subc. and not
necessarily in the integration project, whose main expertise will be in
integrating all ONAP pieces, producing the right lab environment, and verify
that ONAP does what it is supposed to do. Somewhere very close to test start
time you would expect the integration team to gain some expertise in the
specific use case - but this will be very close to the time it needs to be
tested and long after development of this use case in the various projects has
started.
Since this is not about ONAP architecture but rather about the use case
architecture - these expertise would also not necessarily reside in the
architecture subc.
Therefore the way I understand the flow is:
1. Use case subcommittee discuses new use cases
2. Use case subc produces use case flow diagrams and ONAP flow
diagrams
3. Use case subcommittee gets feedback from the potentially effected
projects including integration team on feasibility
4. Iterate back to 2.
5. TSC approval
6. Detailed per-component flows are defined and projects write their
user stories / implement them; Use case subc continues to accompany the use
case development, review epics/user stories, answer questions, etc. (behave as
system engineers for the use case) through test start date
7. Integration project leads (coordinates) effort to get the use
case tested, repaired, and verified
Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Stephen Terrill
Sent: Monday, June 19, 2017 1:45 PM
To: SPATSCHECK, OLIVER (OLIVER) <[email protected]>;
[email protected]
Subject: Re: [onap-discuss] Use Case Subcommittee Flow
Hi,
I wasn't in the use case subcommittee meeting today, so I was wondering
what is meant by "integration project leads (coordinates) effoerts to get
detailed flows ..." If these are information flows between the components,
then we have 3 places that would be doing such flows: UC subcommittee,
Architecture sub-commiteed, integration project. It seems like too many.
Can we have the use-case sub-committee doing the high level flows for the
use case, only sufficient level to identify the requirements on the components.
The architecture group is having the flows to show the general principles,
then the APIs are done in the proejcts?
BR,
Steve
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of SPATSCHECK, OLIVER
(OLIVER)
Sent: 19 June 2017 16:31
To: [email protected]
Subject: [onap-discuss] Use Case Subcommittee Flow
Based on the discussion in the subcommittee meeting my understanding on how
use cases get worked from the beginning to the end is like follow:
1. Use case subcommittee discuses new use cases 2. Use case subcommittee
gets feedback from community including integration team on feasibility 3.
Iterate back to 1.
4. TSC approval
5. Integration project leads (coordinates) effort to get detailed flows
with the help of the other projects and the release manager 6. Detailed flows
are defined and projects write there user stories/implement them 7. Integration
team tests flows and use case
Did I capture this correctly? Does that make sense to everybody?
Thx
Oliver
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
<https://www.amdocs.com/about/email-disclaimer>
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
<https://www.amdocs.com/about/email-disclaimer>
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
