Further development

The Maritime MaaS interface has been created during a project with the same name, and the aim is to make it an integral part of the business activities of maritime operators and MaaS operators interested in selling retail tickets to scheduled water transport. This project wiki’s description is part of the management model created for the interface, whose purpose is to support the use of the interface now and in the future, so that the interface’s lifecycle can exceed the duration of the project.


Principles of further development


The development of the Maritime MaaS interface is carried out according to specific principles connected to technical quality, quality assurance, a systematic approach, i.e. a described development process, and an estimated added production value to the network of operators using the interface, resulting from the development.


The first process description of the further development measures will be created at the end of 2021, and the process will be adapted according to how the network evolves.

Technical quality


The technical quality of the interface development consists of several elements, which have been briefly outlined below:

 

Quality factor

Description

Information location

Technical documentation

Technical documentation of the interface, GTFS recommendation and recommended ticket data model

LINK

Version control

A transparent version control model of the interface’s technical development

 

Guidelines for the technical aspects

Standards applied, descriptions of best practices, application examples contained by the technical documentation and potential examples of models

 

 

Automated tests and testing instructions

A description of testing options and instructions for carrying out tests, so that the quality of changes and integrations implemented in the production will match the target



Code review prior to transfer to production

A peer review of a code produced to verify production quality and compatibility with the guidelines

Carried out as part of the Implementation Support

Vulnerability assessment

Vulnerability testing carried out by an external expert at specific intervals on the latest development



Change management

A description of how change management is carried out and how the network members and operators that use the interface are informed of this management



A description of the principles of further development and the process

A description of the principles that guide further development, the way in which further development is carried out and the roadmap of this development



Service level agreement

A description of the service level agreement on the interface to its users

LINK

Terms of use

The terms of using the interface that describe the responsibilities and obligations of operators that use the interface

LINK

Document updates

The interface has a designated operator to manage its technical documentation and ensure the availability of a version that matches the latest production version





Process of further development


The process of further development describes the way in which the needs of further technical development and the individual preferences regarding the development of the interface are shared with the network, allowing the network members to make justified decisions about their implementation, implementation schedule and cost distribution.


Here, network members refer to operators that use the interface, i.e. have integrated with the interface and therefore the interface administrator has their contact person’s/persons’ contact details.


Further development proposals and those selected for implementation are published at an agreed on location, so that all those using the interface or planning to use it, as well as operators interested in the development of the interface’s functionalities, will have access to up-to-date information at all times.


A simplified development model (see image below) starts from the identification of development needs and moves on to their general assessment, selection of functionalities to be created, prioritisation into a backlog and implementation. Then, another assessment is carried out on user experience, after which the cycle is repeated.

 

 

Ensuring added value through further development


An integral part of the coordination of further development is to ensure that the functionalities selected for development will benefit the interface users as extensively as possible. In order to achieve this, the network of interface users must be consulted. Possible means to do this include:

  • providing a sufficient description in the backlog and prioritising these during the initial stage through a vote

  • holding regular planning sessions with the operators to discuss needs that have come up and decide which ones will be implemented

  • having a work plan, including prioritisations, that is regularly shared and justified by the administrator, created by consulting the operators, and allowing the operators to comment on it before its initiation.

 

Features required at the end of the operating season must be created between November and March. The season’s start date varies, taking place in April, and the season continues until the end of October.


The method with which further development is funded will naturally affect the way that the development is organised. However, operators must be consulted as part of this work, so that the interface can continue to meet their real-life needs.


To achieve this, the network must have a feedback channel via which operators can state their development needs and describe these needs. They must also be able to provide information about functionalities that they themselves are planning to create and make available to others by using the code base.

Vesiliikenteen MaaS -hanke - Maritime MaaS project
Marite MaaS API documentation 2021-2022
Forum Virium Helsinki & City of Helsinki