cessda-decisions.md



CESSDA – Decisions

CA3: Extensibility
MUST be SML3:
„Use is possible by most users: Future extensibility is designed into the system for a moderate range of use cases. The
procedures for extending the software are defined, whether by source code modification or through the provision of some
type of extension functionality (e.g., callback hooks or scripting capabilities). Where source code modification is
part of the extension plan, the software is well-structured, has a moderate to high level of cohesion, and has
configuration elements clearly separated from logic and display elements.“
Actions to Be Taken in RDD:

Future extensibility is designed into the system
on RDD developer level
source code modification --> software is well-structured
provision of some type of extension functionality --> use of frameworks such as templating engines and localization
frameworks
configuration elements clearly separated from logic and display elements
use SADE as example project


CA4: Modularity
MUST be SML3:
„Use is possible by most users: There is evidence that the architecture is open, with full structuring into individual
components that provide functions or services to outside entities (i.e., open architecture); internal functions or
services documented, but not consistently; modules have been created for generic functions, but modules have not been
created for all of the specified functions; code within each module contains many independent logical paths.“
SHOULD be SML5:
„Demonstrable usability: It is evident that all functions and data are encapsulated into objects or accessible through
web service interfaces. There is consistent error handling with meaningful messages and advice, and use of generic
extensions to program languages for stronger type checking and compilation-time error checking. Services are available
externally and code within each module contains few independent logical paths.“
Actions to Be Taken in RDD:

we NEED consistent error handling with meaningful messages and advice
if specific errors can occur --> create explicit errors
return and input types must be defined if language allows types
think of possible reuse of internal methods --> make them externally available
one module serves one purpose


CA6: Portability
(target platform: e.g. Docker container)
MUST BE SML5:
„Demonstrable usability: The software is completely portable to the target platform. In theory at least, the software
will run on the target platform provided it is packaged/containerised.“
Actions to Be Taken in RDD:

examples for target platforms: TextGridLab (Windows, Linux, Mac OS), Java Web Services (Web Application Server:
Tomcat, etcpp), SADE (eXistDB, Linux, Windows), DiscussData-Django-App (jeder Host, für den Docker verfügbar ist)

++ Michelle möchte, dass wir mehr über Docker sprechen! ++

CA7: Standards Compliance
MUST BE SML3:
„Use is possible by most users: The software and software development process comply with open, recognised or
proprietary standards, but there is incomplete verification of compliance. Compliance to recognised standards has be
tested but this may not be for all components. There is documented evidence of standards being used, but not of the
verification of components.“
Actions to Be Taken in RDD:

coding standards: code style, git (commit hooks), gitflow/gitlabflow, (semantic) versioning
software standards: documentation (JavaDoc, OpenAPI, etcpp), data and metadata formats, APIs (REST, SOAP, OAI-PMH,
etcpp), license
CI standards: release workflow (?), deployment


CA8: Support
MUST BE SML1:
Actions to Be Taken in RDD:

an organizational e-mail-adress must be provided with the readme and in a convenient view, e.g. imprint/help/info
etc.

SHOULD BE SML3:
Actions to Be Taken in RDD:

provide support "near" the source code (discussable)
by any means, provide it in one location
regular and planned releases


CA9: Verification and Testing
Actions to Be Taken in RDD:

CESSDAs definitions seems a bit unclear to us
without referencing the SMLs we link our test chapter to CESSDAs document


CA10: Security
MUST BE SML2:
Actions to Be Taken in RDD:

every developer must have had a basic security training

SHOULD BE SML5:
Actions to Be Taken in RDD:

address security in every step of development (design, implementation, testing and verification, release)

TODO:

mit AL über Training für alle Developer sprechen
Anforderungen an Softwaresicherheit formulieren
Training erarbeiten (mit Security-Issue-Liste beginnen)


CA11: Internationalisation and Localisation
MUST BE SML1,5
Actions to Be Taken in RDD:

locale awareness is a high requirement for software with a monolingual target audience but you must provide it in
english (and/or the target language) at least

SHOULD BE SML3
Actions to Be Taken in RDD:

if applicable, i18n and l10n frameworks should be used

nice to read:
https://bridge360blog.com/2011/11/25/software-design-considerations-for-internationalization-and-localization/

CA12: Authentication and Authorisation
MUST BE SML2
SHOULD BE SML4
In this case we cannot give a general recommendation since the way authentication and authorisation is implemented
inherently depends on the software's functionality. Instead of developing an own solution rely on DARIAH's AAI whenever
possible.
Actions to Be Taken in RDD:

never share passwords
use Shibboleth whenever possible and reasonable