PODeliverable Review Form

General comments

1. The document is technically very sound. You have provided a good reference for the formulation of the area work plans and guide the development work.
   The document would greatly benefit from having a chapter on EMI technical strategy. What is the technical direction we are taking? What are the guiding principles in our development work? Why have we chosen to implement these objectives in year 2. What would be the impact of our chosen strategy wrt over-all project objectives, wrt realision of the vision to have a sustainable infrastructure and more usable reliable mw. How does the technical plan complement/provide input to the year 2 plans of NA2, SA1 and SA2?
   
   

BK: Most of the review recommendations, just like the above one, either relate to the overall structuring of the Technical dev plan or suggests completely new content to be added. The implementation of these recommendation would take several days at least. I tend to agree with almost all of them (see details later) or at least ready to consider them. Unfortunately, not for this version of the plan because of the very limited available time. There is simply no time for any bigger change :(. Concerning the EMI Technical strategy and technical directions, i need to understand what is meant by those terms in this context and how is that different from roadmap/vision or prioritization of objectives. This suggestion needs clarification. Then, concerning how DNA1.3.2 influences the NA2, SA1 and SA2 activity year 2 plans, i don't think this is within the scope of a tech development plan. In section "Purpose" i tried to place this document in the context of all the other deliverables but i don't think i should tell in this DNA1.3.x what and how SA1, SA2, NA2 should consume the tech plan.

ADM: This is an NA1 Technical Development Plan, it should describe the overall technical vision and its evolution. The technical objective follow from a combination of the vision and the requirements. My concern is that without a solid section on the technical vision the objectives may look out of context. Also the impact of the vision on the project and its activities should be explained. If we do x, it means that JRA1 will have to do y, SA2 z and SA1 w. A very trivial example is support for OSs: we have a requirement (support sl6), we transform it in an objective for JRA1 (implement support), this means that SA2 has an objective (update the build system and testbed) and SA1 has an objective (prepare the release for a new platform and get ready to support it). NA1 should provide this type of coordination and glue information as part of its deliverables

1. Requirements:
   Can we add a section on EMI requirements solicitation, analysis, selection and prioritisation process?
   
   

BK: No, that i wouldn't do and i don't think that the requirement processing policy is in the scope of a tech dev plan. BUT: as i have requested earlier, SA2, together with PTB, should define "EMI requirement policy" as a separate document. The "requirement handling policy" should cover how requirements are submitted (who can do that?), how are those analysed, prioritized, then turned into part of the workplan and finally resolved by shipping a product implementing the request. This "EMI requirement management" policy is very much missing. Some job for SA2.

ADM: Collection of requirements, interaction with the EGI TCB, with WLCG, with user communities is the main source of input for defining the objectives and it is work that you have done. Without this description it is difficult to explain why we decided to do A instead of B. We may need a separate internal document, but this is a project deliverable that is expected to tell the reviewers how we do things and why. Whereelse will they find that information?

1. Year 1 status and year 2 plan are diffused in the text. It would help if these are clearly separated ie Ch3 Requirements Ch 4 Products could benefit from having subsections status report and year 2 plan. Alternatively, follow the general structure of the Technical Area Work Plans ie Ch3 Status Report Ch 4 Technical Plan
   
   

BK: This suggestion can be and will be considered for the next version of the tech plan, the DNA1.3.2. Though, please remember the real status report is done in the corresponding area workplans. On the DNA1.3.2 level the status info is just really a flag (done, not done) and separating this off from the e.g. product or objectives table may not be the best idea. In any case, i'd need more info about what exactly should go into a separate "requirements status report", "product status report" or a "objectives status report" section. I am afraid it would introduce lots of duplication. Again, status info on the DNA1.3.2 level is very brief, the real status/progress should be reported in the area workplans.

ADM: No project-wide status reports? We should report on how the assumptions and plans set in the DoW and the first technical plan have evolved. Is the situation still the same? Any technological trend or change that impacted us or that we should follow

1. Document structure- top-down or bottom-up?
   Vision/Requirements->strategy->plan->sw portfolio/dev objectives (in fact this should be a virtuous cycle). If you agree with this, a slight re-organisation of the content/presentation may be needed. Would a diagram help?
   
   

BK: This is a big structural change. It may be followed for the next version of the deliverable. Not to mention that some ingredients of the proposed cycle is not really clear to me (vision vs. strategy vs. plan ). Let's come back to this proposal next year when the TOC of the DNA1.3.3 to be settled.

1. Executive summary:
   I am missing the overall year 1 status assessment wrt DNA131 technical plan. Have all the planned objectives been achieved? Have all the year 1 requirements been addressed?
   I would also like to see the key harmonisation and evolution highlights planned for year 2. What is the motivation behind these objectives? What are the guiding principles behind the course of action? (see point#0)
   
   

BK: As i wrote above, the DNA1.3.2 is not the proper document to report about progress. For me, DNA1.3.x is the document that contains the updated plan. The status/progress reports are done in the dedicated area workplans and i see no reason to duplicate that in the DNA1.3.x. However, to make this clear i expanded the first paragraph of the Executive summary. Concerning the requirement: yes, year 1 requirements from DNA1.3.1 had been incorporated into the workplan objectives already back in the DNA1.3.1. Year 2 requirements presented in DNA1.3.2 are captured by the new objectives. Then, for the harmonization and evolution highlights i have added a new paragraph listing these highlight.

ADM: There is no other document to report about progress at the project level. You will certainly be asked to report about how the project progresses in general and an assessment of year 1 achievements. The updated plan is of course the second part, but how can you explain the second part without explaining how you came to the decision of defining the new objectives?

1. Requirements Table:
   Can we add another column 'date submitted' (by the requester?)? This could be the actual date or simply year 1/ year 2. This gives us a sense of evolution, over time, of the requirements.
   
   

BK: I was thinking of a "submitted column" but then turned it down since all the requirements in the table were received at the same time, "year 2". Such a column will be added next year, this will be done for the DNA1.3.3.

1. DCI collaboration:
   we have joint development work with DCIs eg inteoperability plugins with EDGI, clouds with StratusLab, globus with IGE, etc. I think development work resulting from DCI roadmap deserves some discussion. Currently it is mentioned in the Conclusions only.
   
   

BK: I would rather not add such info into the DNA1.3.2. Don't we have a separate deliverable(s) for this? Collaboration something? If you feel a strong need for such info, please feel free to add a paragraphs somewhere (where?).

ADM: we have deliverables explanining the general collaboration plans on a networking level, but there is nothing describing the collaborations at technical level. Actually the EMI Roadmap deliverable explicitly mentions the Technical Development Plan as the place where the technical aspects of the collaborations are explained. All the work done with the EGI TCB for example in the progressive implementation of the DCI Vision should be reported here.

1. Standardisation, integration, release strategy, QA: you indicated these are out of the scope of DNA132. Nevertheless, if you agree with point #0, the EMI technical strategy should include the direction we will take wrt to these areas to achieve the technical objectives.
   
   

BK: I'd postone this as well. Next year the new SD can be asked to contribute to the DNA1.3.3 with such standardization strategyy section. but do we really need that here? we already have dedicated std deliverables. The same applies to release and QA strategy, i don't really understand what part of these areas should be included in DNA1.3.x. Let's discuss this for the next version of the DNA1.3.3.

ADM: Again, they would provide the context for some of the objectives. You can refer to other deliverables for more details, but this document should be the master document glueing everything together.

8. Missing EMI strategy on grids and clouds interop

BK: we don't have such a strategy yet. The only thing we have at the moment for clouds is an objective due month 18 to deliver EMI cloud strategy. I hope the new SD will contribute with a mature cloud strategy to the next update of the tech plan, to the DNA1.3.3 next year.

ADM: we don't for sure, but we should explain why we plan to have it, what discussions we had in the first year, whether the collected input from various meetings, conferences and discussions has changed in any way our priorities and if not, why not, etc.

9. GANTT chart: More than the area deliverables, DNA132 can benefit from having a gantt chart, to show at least the interdependies.

BK: In view of the "gantt agreement" please add the relevant paragraph pointing to an external gantt chart to the right place in the DNA1.3.2 while you are fixing the cover page. Then, it is up to Morris to prepare such a chart.

Morris is preparing the charts for the JRA1 deliverables and we agree that the Gantt frenzy should be moderated. Nonetheless having some easy way of showing the timelines and the major milestones and dependencies would be beneficial

10. Avoid, if possible, to use wiki references [R4]

BK: i tried hard. but i can't help if important tech material is only available in the wiki (security area is the worst in this respect).

ADM: if necessary documents can be copied to CDS and referenced from there

11. Conclusions:
"Plan is the main reference document driving the identification of requirements" - isn't it the other way around?
Software Development and Test Plan (SDTP) - what is this? is this year 2 update of EMI Development and Test Plan? when is this due? who is doing it?

BK: "driving the ..." There the driving was a wrong word. The sentence is actually about the content of the plan, thart is it contain requirements, so on. I replaced "driving" with providing.

ADM: I'm still not sure "providing" is the right word. The plan should follow from the identification of requirements. Maybe this should say "The plan is main reference document describing how identified requirements are implemented"?

BK: Concerning the SDTP, that is Alberto's idea (actually the entire conclusion was written by him last year, i just refreshed it a little bit this time), According to my understanding, the STDP is the real workplan on the PT level. As if we agreed to turn this SDTP into tracker entries, it won't be a document. The JRA1 leader will have to do this and back in Lund, i offered my help. Lots of things has changed since then, so i don't know who would do it and by when. All in all, please ask Alberto what he thinks about the SDTP and if he agrees, that paragraph can be removed from he conclusion (i wouldn't mind). I did no touch it because Alberto found it important last year.

ADM: I'm fine with stating that the STDP has been turned from a document into a process+tracker, although this should still be explained somewhere.

-- FloridaEstrella - 23-May-2011