-
Notifications
You must be signed in to change notification settings - Fork 42
openETCS States of WP3 Software deliverables
Initial draft version 10.7.2015
For deliverables used in production of the openETCS runtime model the state of the deliverables has to be documented in the github readme files for each of the deliverables. States are in use for Scade models and for other deliverables like C-Code. In this description the term function either refers to a Scade project or a C- project.
The function owner (a dedicated person representing the function in the weekly meetings) is responsible for updating the status.
Status updates from a more severe state to a lower state (e.g., in verification -> in work) have to be agreed on in the weekly meetings.
The progress according to the status has to be planned at the beginning of each iteration. This is typically the time to change from a higher to a lower state. Alternatively, the team can agree to plan for changes in a function in an upcoming sprint.
When implementing some functionality the analysis will be stated based on the description of use cases and user stories. In practice, a change for a user story will impact several software functions. So, the states of user stories and the staes of functions (i.e.., models) are describing different views on the work. You can compare this approach with the traditional matrix of project organisations.
no official code on github. The function is planned to be implemented.
No checks on the model and no integration of parts of this model are done.
the function is being implemented. The function is not delivered to any openETCS integration model.
Interfaces are to be seen as a proposal.
Interfaces are fixed. Agreed (sub-) functions are code complete and can be used in the integration. The function has to be error-free compileable and buildable. Parts of the function are in use with the integration models.
Interface changes between functions have to be agreed on and need to be delivered in a coordinated way. Best Practice is to agree on changes in the weekly WP3 meetings.
function is in verification. Code is complete. Changes may happen due to error corrections. No interface changes are allowed if not agreed on in the weekly meeting.
function is frozen. Code changes and interface changes have to be planned in the weekly meetings.
Please, refer also D3.2.a "Definition of the openETCS Development Process", "A Standard-Compliant Process for the EVC Software Development"