End of a Project
Project proposals are focused on their scientific domain, and are not always clear on the necessary escience. Also, during a project the escience requirements can change, and its actual escience component can be different from the originally proposed methods and tools. A final project report will focus on the scientific domain (published papers) and financial accounting. All in all, this leaves the escience part of projects a bit undocumented. Therefore, we could use a small informal document, for internal use, describing the project from the perspective of an escience engineer. In principle the escience is shared with the engineer and coordinator, and is discussed during the project reviews. Any reusable software is added to eStep, or to the knowledgebase. This document can therefore be high-level and short. It is meant to facilitate re-using tools and techniques for other escience projects, provide (links to) information and background material for escience presentations / PR, and provide a possible starting point for continuation of the project.
As this kind of documentation is only valuable if engineers can freely share their opinions and experiences (also negative ones!), this document itself is not meant for external distribution.
- high-level description of actual escience requirements in the project
- what went great, what could have gone better
- pointers (URL) to project documentation
- motivation for chosen approach,
- high-level description of used or developed tools and references to them (github, website, )
- eScience presentation for (re-)use in the form of a powerpoint document (so the images, text, and or slides can be extracted). Check the pitch and project presentations to see if they are sufficient, ask coordinator.
- escience engineer(s) working on the project
- escience engineers
- escience coordinators
- should be written during the last weeks of the project
- Stored on the internal sharepoint site
The Netherlands eScience Center provides very limited support for software. During a project we make every effort to create low-maintenance code by building on as many standard components as possible, using software from eStep, and putting a lot of effort into documenting and testing software. Also, by using standard file formats and API's we try to limit the effort required to maintain software, and make it easier to continue development.
After a project has finished the eScience Center will in principle not further support the software. Reported bugs in our own software will of course have a high chance of being looked at, but this also has its limits. We cannot in any way contribute to the administration of infrastructure needed after a project has ended.
Because of the lack of support after projects is is a good idea to start to think about and make agreements on where software will land and who will maintain infrastructure at the very beginning of a project. The project proposal should already contain a plan.
For in-house developed eStep software we do provide some support, though even here only limited time is available for this. See the technology page on the website (https://www.esciencecenter.nl/technology) for the list of supported software.