TWiki> EMI Web>TSA14>SA1QCRSRS>SA1QCPM6 (revision 10)EditAttachPDF

PM6 - End of October 2010

Author

CINECA

Review of the Software Release Plan

Description

Checklist

Check # Question Response
1 Dose the list of supported platforms correspond to the actual set of platforms on which software components are released? N.A.
see https://twiki.cern.ch/twiki/pub/EMI/DeliverableDSA12/EMI-DSA1.2-SoftwareReleasePlan-v0_4.odt , chap.5
see https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ConfigurationIntegrationGuidelines
see https://twiki.cern.ch/twiki/bin/view/EMI/TSA13
2 Is the installation of external dependencies well documented? N
see http://eticssoft.web.cern.ch/eticssoft/internal/public/VMWareImages/EMI_SL5_x86_64_EPEL_rpmlist.txt
3 Are instructions to build the software up to date? Y
see https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ConfigurationIntegrationGuidelines
4 Is the list of supported delivery software formats up to date (source and binary packages, tarball, package lists, etc)? N.A.
see https://twiki.cern.ch/twiki/pub/EMI/DeliverableDSA12/EMI-DSA1.2-SoftwareReleasePlan-v0_4.odt , chap. 4.5.5
5 Is the description of the process on how to handle changes up to date? Y
see https://twiki.cern.ch/twiki/pub/EMI/DeliverableDSA12/EMI-DSA1.2-SoftwareReleasePlan-v0_4.odt , chap. 4.2
see https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangeManagementGuidelines
6 Are the communication channels published with updated information? N.A.
see https://twiki.cern.ch/twiki/pub/EMI/DeliverableDSA12/EMI-DSA1.2-SoftwareReleasePlan-v0_4.odt , chap. 4.5.5
7 Is the process on how to deliver software to the Production Infrastructures up to date and itís aligned to what the Production Infrastructures are expecting? N.A.
see https://twiki.cern.ch/twiki/pub/EMI/DeliverableDSA12/EMI-DSA1.2-SoftwareReleasePlan-v0_4.odt , chap. 4.5.5

Comments

Check # Comment
1 the software has not been released yet so no comparison is possible.
2 what does it mean exactly ? Installation inside ETICS ? Or for the final user ? Anyway there is no documentation in both cases.
4 No list available.
6 No communication channels available.
7 No delivery process available, no Production Infrastructure requirement document available.

Metrics

No metrics defined for this report.

Review the Software Release Schedule

Description

Checklist

Check # Question Response
1 Has the previous schedule been kept? N.A.
see https://twiki.cern.ch/twiki/pub/EMI/DeliverableDSA12/EMI-DSA1.2-SoftwareReleasePlan-v0_4.odt , chap. 4.6
2 Does the new schedule take into account what wasnít accomplished in the previous schedule? N.A.
see https://twiki.cern.ch/twiki/bin/view/EMI/TSA13
3 Is the new schedule aligned to the Software Development Plan and the priorities of the project? N.A.
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDNA131
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA111
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA121
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA131
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA141
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA151
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDJRA161

Comments

Check # Comment
1 No clear schedule defined.
2 What does it mean exactly ? Where the new schedule is supposed to be published ? Anyway there is no documentation.
3 No clear schedule available. In the Technical Development Plan and in the various detailed plans, there aren't Gantt graphs or tables representing a clear roadmap. Just pieces of information scattered among various paragraphs. In some cases they report vague sentences like "during the first year" so it is not possible to perform a real check. Moreover, even when there are dates, there isn't a reference to a document or a product which allows to verify that the deadline has been matched.

Metrics

Id Name Description Unit Measurement Note
DELAYONTHERELEASE Delay on the release schedule This metric could be provided as a histogram showing the delay time (in days) for each release, weighted using the release time (release delay)/(release time) * 100 N.A. The first EMI release, internal-release, will be made available at the end of October and thus no measurements for this metric can be collected.

Review the Software Maintenance and Support Plan

Description

Checklist

Check # Question Response
1 Is the process on how to handle incidents reported by EMI users using GGUS up to date? Y
see https://twiki.cern.ch/twiki/bin/edit/EMI/DeliverableDSA221?topicparent=EMI.EmiDeliverables;nowysiwyg=1
see https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangeManagementGuidelines
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDSA11
2 Is the process on how to handle requests coming from EMI users or other PTs up to date? Y
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDSA11
see https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangeManagementGuidelines
3 Is the process on how to handle problems up to date? Y
see https://twiki.cern.ch/twiki/bin/view/EMI/DeliverableDSA11
see https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangeManagementGuidelines

Comments

The GGUS documentation does not include any reference to EMI.

Metrics

Id Name Description Unit Measurement Note
TOTALUSERINCIDENTS Total user incidents per user month This metric covers defects not only in the software but also in the documentation, training and user support processes, per user month. User month means the number of users (in our case, deployed services?) Per month. GGUS tickets per user per month N.A. The first EMI release, internal-release, will be made available only at the end of October and thus no measurements for this metric can be collected. However if we were to start measurements collection tomorrow, we will be able to collect measurements for gLite and dCache only.

Id Name Description Unit Measurement Note
TRAININGSUPPORTINCIDENTS Training and support incident per user month. This metric covers defects in the training and user support processes, per user month. User month means the number of users (deployed services?) per month. The training and support defects can be derived by subtracting the tickets in status unsolved (ticket that generated a bug) from the total number of opened tickets. It relies on proper bug opening from GGUS tickets, especially for what concerns ambiguous or missing documentation Incident per user month N.A. The first EMI release, internal-release, will be made available at the end of October 2010 and thus no measurements for this metric can be collected. However if we were to start measurements collection tomorrow, we will be able to collect measurements for gLite and dCache only.

Id Name Description Unit Measurement Note
AVERAGETIMEFORUSERINCIDENTS Average time to deal with an incident at the 3rd level of user support This metric wants to measure the effectiveness of a product team to provide 3rd level user support. The time is measured from the time the ticket reaches a PTís 3rd level support and the time the ticket is moved to the status solved or unsolved Days N.A. The first EMI release, internal-release, will be made available at the end of October and thus no measurements for this metric can be collected. However if we were to start measurements collection tomorrow, we will be able to collect measurements for gLite and dCache only.

Security Assessments

Description

Comments

The security assessment plan has not been release yet and no checks can be performed for this review.

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r10 - 2010-10-20 - GiuseppeGiacomoFiameniExCern
 
    • 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-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback