Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI Deliverable or milestone identifier: D1.3.3
Title: DNA1.3.3 - Technical Development Plan (M23) Doc. identifier: EMI-DXXX-CDSREF-Title-vx.x
Author(s): B. Konya Due date: 31/03/2012

Identification of the reviewer
Name: A. Ceccanti Affiliation: INFN EMI Activity/External project or Institute: SA1

Review date mm/dd/yyyy
Author(s) revision date mm/dd/yyyy
Reviewer acceptance date mm/dd/yyyy

Attach the reviewed document to the deliverable page, put here a link

General comments

The deliverables as it is now is too much a list of things without a clear context. It lacks details on the status of what was achieved during year two, what was not achieved and why. For year three, it is not explained what is the rationale behind the analysis of the requirements, the prioritization of the objectives and their relationship with the requirements. A reference to the requirement in the objectives table would help. Globally the deliverable lacks technical insight. Pointing to area deliverables is not enough, and has already raised negative feedback from the reviewers at the end of first year. The deliverable should be self-consistent, summarizing the information provided in the area deliverables and giving a clear overview of the work done and planned, of the issues faced up to now and the rationale behind the technical decisions.

This deliverable fails in delivering a clear architectural view of the EMI software portfolio, a lack that was highlighted at the first year review (but wrongly targeted at the DSA1.1 deliverable). The products table does not help in understanding what EMI provides in terms of services and functionalities. Also the granularity of the table (e.g. 6 products make the CREAM CE) might not be understood by external reviewers. Building from the EMI fact sheets could be a good starting point to have a better description of the EMI software portfolio.

Other specific remarks in the attached word document.

21/05 Balazs: Thanks for the review, i partially share your opinion (see below) but unfortunately the available very limited time does not allow to make big changes in the document. Then, for me the DNA1.3.x tech plan deliverables were always looked at as important factual tables, a document that presents and defines crucial "EMI stuff" such as key tech directions and the software stack. All in all, for me DNA1.3.x is rather a "reference manual" and not a "user guide" Achieving this, e.g. creating a reference document with this core data is alone not easy and even after the second iteration the result is not perfect. For example, everybody defines "product" differently.

Then, the justification of decisions and a nice "architecture-style view" would be nice but there was just no time for it.

Below i try to respond your statements one by one.

> General remarks:
>
> The deliverables as it is now is too much a list of things without a clear
> context.

Balazs: Yes, the real content and value of the deliverable is in those tables. For me those lists constitute the "content" of the deliverable. Regarding the context, i believe it is set, the three important tables (requirements, portfolio and dev objectives) are pretty well-explained.

you may criticize that the tables contain too many entries but that is the reality, that shows how fragmented the EMI portfolio and the related development is. We should not hide the obvious: EMI is a distribution of loosely coupled mostly independent products. This is reflected in those tables.

> It lacks details on the status of what was achieved during year two,
> what was not achieved and why.

As stated in the scope section, that details should be delivered in the area documents. However, high level status per objectives are given, the objectives table clearly states what was or was not achieved. The "why something is not achieved" is not within the scope of this deliverable, i believe.

> For year three, it is not explained what is
> the rationale behind the analysis of the requirements, the prioritization of
> the objectives and their relationship with the requirements. A reference to
> the requirement in the objectives table would help.

this is true and myself also find it as a shortcommings. Btw, Diana commented about the same and i gave her this reply:

"Originally I thought of this, i.e. to somehow link the objectives to the requirements but when I started to do it it become very complex. This is due to the complex nature of the requirements. The requiremen analysis and the following objective definition and review took several weeks of the PTB and it is impossible to incorporate the outcome in a simple table."

> Globally the deliverable
> lacks technical insight. Pointing to area deliverables is not enough, and has
> already raised negative feedback from the reviewers at the end of first year.

The DNA1.3.x is deliberately not the place to explain the details. In my reading the reviewers did not criticize the DNA1.3.2 for lack of details.

> The deliverable should be self-consistent, summarizing the information
> provided in the area deliverables and giving a clear overview of the work
> done and planned, of the issues faced up to now and the rationale behind the
> technical decisions.

I see a different main purpose for this deliverable. As stated earlier, for me it is a key technical document, a reference book for EMI. It is not a guide or dissemination document, it is a document that sets important EMI facts through couple of tables. Please recall that e.g. the EMI software portfolio was not even known before the first version of the DNA1.3.x came out!

Anyway, it is too late now to make bigger changes and your comment above would require a major rewrite/extension of the document.

> This deliverable fails in delivering a clear architectural view of the EMI
> software portfolio, a lack that was highlighted at the first year review (but
> wrongly targeted at the DSA1.1 deliverable).

This is true. An EMI architecture is not there. However, i am not sure there is any such architecture... EMI is a distribution, have you ever seen fedora architecture? Or if by "architecture" we mean a better classification of products by their functionality, then such a thing rather belongs to SA1, or even NA2, NA3 as "marketing" or product positioning

> The products table does not help
> in understanding what EMI provides in terms of services and functionalities.

agree. the PT table is "just" an inventory and definition of the software stack. It was never intended to be more than that. The product descriptions and classifications are details that out of the scope of this high level "reference manual"

> Also the granularity of the table (e.g. 6 products make the CREAM CE) might
> not be understood by external reviewers.

the granularity is taken, provided by the product teams themself. What can i do if different teams define their "products" differently? not to mention that the DNA1.3.x product definition is still not in perfect match with the actual products the PTs release or support.

> Building from the EMI fact sheets
> could be a good starting point to have a better description of the EMI
> software portfolio.

again, the products table should be seen as a reference table, a table that defines what is EMI and what is not. It is not the table that explains or try to sell the stuff itself. I agree that the factsheets are better in this sense.

> Other specific remarks in the attached word document.

see my responses as comments in the attached file. smaller changes got directly implemented in the master copy (v0.7) and got accepted in the commented version.

Additional recommendations (not affecting the document content, e.g. recommendation for future work)

Detailed comments on the content

Note 1: The reviewers must list here any observation they want to track explicitly and that require interaction with the authors
Alternatively all changes must be listed in the document itself using Word change tracking features (if you use Word)
Note 2: These comments have to be explicitly addressed by the authors and the action taken must be clearly described

N Page Section Observations and Replies Is Addressed?
1 xx x.y Sequence of comments and replies separated by twiki signature and date    
2          
3          
4          

Any other modification, spelling or grammatical corrections, etc must be done directly in the document using tracked changes or similar mechanisms that allows the authors to identify which correction is suggested.

-- FloridaEstrella - 03-May-2012

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2012-05-21 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback