Difference between revisions of "DJRA1.1 Report on Knowledge Ecosystem Supporting Technology Development"

Revision as of 04:04, 10 July 2010

Introduction

The goals of the work package JRA1 Knowledge Ecosystem Implementation are to provide the technology realising the common practices, standards and solutions identified by the NA4 work package and enhance and consolidate the gCube system to match the needs of the ecosystem approach. A primary role of JRA1 (played within TJRA1.2) is to address the various interoperability issues inherent in the construction of a knowledge ecosystem, and then identify and implement proper solutions. Ranging from content-related problems to architecture-oriented issues. Major inputs for this part of the work come from DNA4.1.

An Agilish development methodology (referring to no specific Agile development platforms, but to the general idea of quickly responding to change) is driving the teams in JRA1. Plans are sketched and verified with the management boards and user communities; seeing and playing with the system being the most important thing and preferred to over-planning.

This deliverable documents the gCube technology by reporting on the overall status of the system architecture, the per service tasks and enhancements, and other technical details needed to have a comprehensive understanding of the developed knowledge ecosystem enabling technology.

The deliverable is implemented through a Wiki page to be easily and promptly adapted to reflect the ever-evolving status of the developed technologies. For the same reasons, performed and planned activities are reported via dedicated TRAC reports, created for this very purpose.

State of Software Development Activities

This section reports on the current maintenance and upgrade activities on the gCube system.

To have a living picture of the continuous evolution of the system, the project's TRAC instance has been properly exploited in the following manner:

• firstly, four dedicated milestones have been defined:

• Short-Term gCube plan, used when the activities described in a ticket are planned to be completed within the next month;

• Medium-Term gCube plan , used when the activities described in a ticket are planned to be completed within the next 3 months;

• Long-Term gCube plan, , used when the activities described in a ticket do not have a starting and ending date yet;

• Ready To Release, used when the activities described in a ticket are completed and passed to SA.

The idea behind these milestones is that a developer moves his/her tickets among them according to the work performed or to be performed on each ticket;

• then, JRA1 management asked to each developer to insert his/her own tasks and give an estimation of delivery by assigning one of the milestones above;

• finally, in order to stand over the activities, four TRAC's living reports have been created for this purpose. These reports are introduced in the following sub-sections.

Upgrade Activities

Upgrade activities describe tasks and enhancements that lead to future releases of the gCube technology.

The planned actions are recorded in report #37.

The closed actions are recorded in report #38

Maintenance Activities

Maintenance activities are dedicated to fix defects found in the technology delivered so far and the related documentation.

The open maintenance activities are recorded in report #39.

The closed maintenance activities are recorded in report #40.

Code Metrics

This section will describe and link the JRA Indicators

[TBC]

Code Statistics

This section will report various tables and charts describing the project development.

[TBC]

Documentation

This section will describe the work on the Development and Administrator's Guide

• Developer's Guide

• Administrator's Guide

Software

Development Version

D4ScienceII relies on the ETICS system to automate the way its software (gCube and gCore) is built and tested. In particular, the project has put in place mechanisms to perform daily builds of the latest version of the code committed in the project source code repository. This activity leads to the production of (i) a report of the build activity and (ii) a set of software artifacts including the software package, the source code and the documentation.

JRA1 is responsible for managing the development version (namely HEAD) of these reports and artifacts whose main purpose is to provide a way to

• verify the dependencies among the artifacts
• exchange artifacts among the development teams

[TBC]