Difference between revisions of "EGI-Engage:Software and services"

Revision as of 15:03, 11 November 2015

EGI-Engage project:	Main page	WP1(NA1)	WP3(JRA1)	WP5(SA1)	PMB	Deliverables and Milestones	Quality Plan	Risk Plan	Data Plan
	Roles and responsibilities	WP2(NA2)	WP4(JRA2)	WP6(SA2)	AMB	Software and services	Metrics	Project Office	Procedures

Help and support: quality@egi.eu

This page provides all rules and guides regarding software and services created under the EGI-Engage project.

Any software created under EGI-Engage should be listed and described (license, source code repository, copyright owner) under Software Copyrights and Licenses

Quality

Services

Quality of services produced within EGI-Engage project will be ensured by the adoption of the EGI Services management standard FitSM, a international standard developed by the FedSM project.

Instruction for Tools teams can be found under Instructions Tools teams

Software

The software produced within the project will follow the well established Software provisioning process that has been adopted since 2010, based on the definition of quality criteria, quality verification and software validation in a controlled production environment of the federated EGI infrastructure.

The development activities within the project will augment capabilities of existing open source software. The resulting software code, tools and interfaces developed as part of EGI-Engage will be released as open source code and the full access will be provided via publicly available source code repositories such as GitHub, SourceForge, Subversion (SVN), Concurrent Version System (CVS) etc. Software developers will be able to choose their preferred source code repository to better integrate with existing practices, nevertheless they will need to

ensure that the contribution is openly accessible,
add the metadata information needed to enable reuse,
communicate the URL to the consortium.

Procedure for quality assessment

Requirement:

Each tool should have a production and a testing/devel instance (at least 2 instances in total)

Testing Options:

Each product team should choose between two possible ways to verify the quality of its release:
1. Manual test
2. (Semi-)Automatic internal procedure to test the release

In both cases, tests and short document must be finished by the deliverable deadline in the DoA. Similar procedures can be applied to internal EGI-Engage releases (between to SW deliverables) or to releases related to the core service activities. In these cases the short document is not strictly needed although storing a test report would be useful.

1. Manual Test:

as for the classical deliverables (the documents), 3 reviewers (1 moderator + 2 reviewers) will be assigned to each software deliverable. The WP manager has the responsibility to identify the reviewers.
The reviewers will perform the validation tests on the candidate release
In the case of deliverables containing more than 1 software releases, we will have 3 reviewers for deliverable plus supporting testers
The candidate release should be installed on the testing/devel instance
Tests will be executed within a week. During this period the testing/devel instance should not be updated. Reviewers and developers should agree on the week to perform the tests
Outcome of the testing process will be part of the short document describing the software release

2. (Semi-)Automatic Internal Testing procedure:

the PT should propose to its work package leader a (semi-)automatic procedure to verify the quality of its releases. An example of this procedure is a continuous integration system with a set of automatic/manual tests executed against each built.
this procedure should be properly documented.
the document at point 2) should:
1. describe the process adopted by the PT to create a new release
2. describe the quality tests performed against each release
3. contain instructions to rollback to the previous release in case of issues in production and describe how the risk of data loss (e.g. for A/R and accounting) is managed
the WP manager, in collaboration with the project management, should validate and approve the procedure verifying it can guarantee a good level of quality assessment. 5) Outcome of this (Semi-)Automatic Internal Testing procedure should be reported in the short document describing the software release (including a reference to the document at point 2))

Licenses

New developed software: An OSI-approved license (http://opensource.org/licenses), for any new software developed within the Project;
Further develop software: In order to comply with the open access policy and maximise possibility for reuse of results, EGI-Engage partners, together, agree not to further develop software released with a non-open license and which cannot be re-released using an OSI-approved license.
Existing software: If no existing OSI license is being used for existing software, the adoption of the Apache 2.0 license is possible.

Source Code

In order to comply with the open access policy and maximise possibility for reuse of results, EGI-Engage software code, tools and interfaces that fall under the joint ownership will be published under an OSI-approved license . If no existing OSI license is being used, we propose the adoption of the Apache 2.0 license. Free and unrestricted access to research result is a measurable barrier to uptake by SME’s and can slow down innovation in measurable terms , and the consortium will make it a priority to comply with the Horizon 2020 Mandate in full support of Europe 2020 Initiative’s Economic Growth Agenda.

The work represented by this source file was partially or entirely funded by the EGI-Engage project co-funded by the European Union (EU) Horizon 2020 program under Grant number 654142.

Copyright [yyyy] [name of copyright owner]

Licensed under the [license name] (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at [link to license]

Unless required by applicable law or agreed to in writing, software 
distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 
See the License for the specific language governing permissions and 
limitations under the License.

Acknowledgement for websites

Acknowledgement should be visible at the portals and source code public repositories.
Please contact quality @ egi.eu for customized version of banner

To acknowledge EGI-Engage (Service co-funded by EGI-Engage)

Template:

To acknowledge EGI.eu EGI-Engage (Service co-funded by EGI.eu and EGI-Engage)