search

openETCS / toolchain

WP7: Top Level Project for the toolchain
27 stars 30 forks source link

Review of tracability Architecture (ends 12-Nov-2015) #506

Closed MariellePetitDoche closed 9 years ago

MariellePetitDoche commented 9 years ago

Here my comments on the document linked to #504

Agree. "Derive" is not the right general term for all the arrows. Changed figure 1and used "transform" instead of "derive" and better explained that initial requirements are transformed to subsystem and then HW or SW or data or procedures. I improved fig 2 with better alignement on EN 50128:2011 and used only term "input for" for relations between artefacts at this stage of the document.

V&V not shown at this stage of the document. Added as a note.

  • some non-functional requirements can be introduced (or derived from Cenelec standards) in openETCS quality or project plans. Yes. Do you think we need to show quality and project plans for this document? will those artefacts be >>traced to requirements?
  • in the fig 2 it seems there is a direct traceability between SRS and Cenelec (orange arrow): I am not agree. Removed. I removed initial arrows coming from ISO 15288 vision and focused now on OpenETCS >>only. ISO15288 was just a way to introduce engineering levels and help me understanding scope of >>different requirements and models by asking partners the position in those levels.

in the current state of SRS it is difficult to explicitly defined a traceability between this document and stakeholders requirements. I consider more the SRS in midway between stakeholders requirement and a real System specification, I will put it in parallel of Cenelec and User stories.

OK. Done.

  • I think validation are missing in fig 1 and 2: lots of requirements can not be derived up to SW code only, but will be link to the different test or V&V phases.

OK. Which openETCS document can I read to add missing information?

  • §1.2 and Fig4 , It is necessary to clarify the data dictionary model and how it is defined (textual, SysML, Scade ?) as a Scade representation of it is one of the SW model.

OK. ToDo.

-§2.2.1:

perfectly agree. I had almost same remarks than you when reading this figure the first time and I did >>not dare to remove it until now because it was not mine and because I thought it was "validated" after >>a previous review. As soon as I can express the traceability process through other diagrams easier to >>understand I will remove this initial figure.

  • §2.2.2: This means we consider only functional requirements. User stories, SRS, API or Cenelec are far to contain only functional requirements.

yes because I wanted to focus on Functional formal model that seemed to be "functional". But I >>understand that this model is also behavioral and that we target an executable model, so containing >>non functional requirements. Will update this scenario with other non functional requirements taken >>into account.

  • Fig 7 : I do not think that the "openETCS system designer" is in charge of all the actions. Typically "trace model element to SRS" is made by SW designer, "Create verification view" by a verificator....

OK. This was a "generic" term used to simplify diagram (showing several actors would make it too >>large). I will use a more generic term and will precise the different possible roles according to activities.

OK. thanks for the reference.

  • §3 Ok for me.

-§4.2.3, for the moment the tool is Scade studio (v16.2)

mistake. fixed.

  • §5, in the view of the openETCS toolchain, totally open, I am agree with the left branch (ProR linked to papyrus). However in practice the sysML model has been made with Scade system which contains an old version of papyrus not really compatible with the one in openETCS toolchain. In this case I'am not sure that ProR can be used at system level (which do not allow us to have an open-source tool for traceability !)

OK. will take that into account.

  • § 5.1.2: How is identify the first sentence "If the establishment....." ? Are we sure that we shall always share such a requirement in different sub requirements with different Id ? Are we not going to lost information (for example in this case that ALL the sequence of actions shall be made in a given order) ?

This is initial text (I did not change that assuming that it was validated). I'll look at your point.

  • §5, 6 and 7: Three solutions are proposed: -why ? maybe an introduction in the document is missing to explain its contents and why 3 solutions are proposed

Well: that might be a question of document organization. First version of document mentioned 1 first >> solution and I understood that this traceability solution was far from being perfect. So I have decided >> to investigate on possible improvements through alternate solutions. If this document reflects what IS DONE in the project, then I must focus on the reality only and >>perhaps conclude the document with "current limits". In that case I can create another document that >>would be "proposals for improvements of traceability support by the tool chain".

  • some parts of some solutions are already implemented or largely analyzed (eg. link between ProR and payprus, use of genDoc...) other seems just propositions. It will be nice to have a clear view of what exists and can be used right now, and other elements.

OK. I will distinguish between existing (tested) solutions and ideas for improvements.

To continue depending updating and comments.

raphaelfaudou commented 9 years ago

Thanks a lot Marielle on time spent to give feedback. I will look at them in detail on monday.

raphaelfaudou commented 9 years ago

For all reviewers:

I intend to push a new revision tomorrow that takes into account most of the remarks concerning chapters 1 and 2 and provides clarification on document purpose and organization. Please wait for it before any reading and review

Le 30 oct. 2015 à 17:52, MariellePetitDoche notifications@github.com a écrit :

Here my comments on the document linked to #504

§ 1.1 and Fig 2:

  • in the figure are mixed functionnal, HW, procedural,... requirements, at the top level (for example from User stories or Cenelec Standard) and all seems to be derived up to SW level (I understand that only specification and design of SW appear on the figure, not the Validation). But I think that lots of the initial requirements can not be derived on Sw, but on other activities (quality or project plan, Validation,...) or subsystems (HW, API,...); How it is plan to take into account these exported requirements ?
  • some non-functional requirements can be introduced (or derived from Cenelec standards) in openETCS quality or project plans.
  • in the fig 2 it seems there is a direct traceability between SRS and Cenelec (orange arrow): I am not agree. in the current state of SRS it is difficult to explicitly defined a traceability between this document and stakeholders requirements. I consider more the SRS in midway between stakeholders requirement and a real System specification, I will put it in parallel of Cenelec and User stories.
  • I think validation are missing in fig 1 and 2: lots of requirements can not be derived up to SW code only, but will be link to the different test or V&V phases.

§1.2 and Fig4 , It is necessary to clarify the data dictionary model and how it is defined (textual, SysML, Scade ?) as a Scade representation of it is one of the SW model.

-§2.2.1:

  • Please give clearly definition of the mining of the different arrows (for example "refines" seems to correspond to a SysML definition which is very different from a classical formal definition of "refines").
  • why "Documentation" is an activity ?
  • why "V&V" do not "use" the requirement database ?
  • meaning of the arrows are not clear for me, so I do not understand why there are no linked between System model and requirement database or functional model and requirement data base. The figure need some comments as it is not self-sufficient for those who are not used of these notations.

§2.2.2: This means we consider only functional requirements. User stories, SRS, API or Cenelec are far to contain only functional requirements.

Fig 7 : I do not think that the "openETCS system designer" is in charge of all the actions. Typically "trace model element to SRS" is made by SW designer, "Create verification view" by a verificator....

§1 and 2 : Maybe it will be nice to have a look on QA plan (WP1 https://github.com/openETCS/governance/blob/master/QA%20Plan/D1.3.1_QA_Plan.pdf), definition plan (WP2 https://github.com/openETCS/requirements) and safety plan (WP4 https://github.com/openETCS/validation/tree/master/Reports/D4.2) to have a better view of what would be expected at the beginning of the project.

§3 Ok for me.

-§4.2.3, for the moment the tool is Scade studio (v16.2)

§5, in the view of the openETCS toolchain, totally open, I am agree with the left branch (ProR linked to papyrus). However in practice the sysML model has been made with Scade system which contains an old version of papyrus not really compatible with the one in openETCS toolchain. In this case I'am not sure that ProR can be used at system level (which do not allow us to have an open-source tool for traceability !)

§ 5.1.2: How is identify the first sentence "If the establishment....." ? Are we sure that we shall always share such a requirement in different sub requirements with different Id ? Are we not going to lost information (for example in this case that ALL the sequence of actions shall be made in a given order) ?

§5, 6 and 7: Three solutions are proposed: -why ? maybe an introduction in the document is missing to explain its contents and why 3 solutions are proposed

some parts of some solutions are already implemented or largely analyzed (eg. link between ProR and payprus, use of genDoc...) other seems just propositions. It will be nice to have a clear view of what exists and can be used right now, and other elements. To continue depending updating and comments.

— Reply to this email directly or view it on GitHub.

raphaelfaudou commented 9 years ago

Hi all,

I have just pushed a new revision of document that addresses most remarks from Marielle concerning first chapters (introduction, main expectations concerning traceability, tool capabilities to support traceability). So new document can be reviewed up to chapter 5.1 (included).

Concerning current traceability solution (chapter 5), I’m currently updating description with existing tools and their use according to the 5 phases of development process. So, even if I get material, I still need more time to update it for good quality and precise semantics presentation.

I hope to complete document (update of chapter 5 and chapter 6) for end of this week.

Le 30 oct. 2015 à 17:52, MariellePetitDoche notifications@github.com a écrit :

Here my comments on the document linked to #504

§ 1.1 and Fig 2:

  • in the figure are mixed functionnal, HW, procedural,... requirements, at the top level (for example from User stories or Cenelec Standard) and all seems to be derived up to SW level (I understand that only specification and design of SW appear on the figure, not the Validation). But I think that lots of the initial requirements can not be derived on Sw, but on other activities (quality or project plan, Validation,...) or subsystems (HW, API,...); How it is plan to take into account these exported requirements ?
  • some non-functional requirements can be introduced (or derived from Cenelec standards) in openETCS quality or project plans.
  • in the fig 2 it seems there is a direct traceability between SRS and Cenelec (orange arrow): I am not agree. in the current state of SRS it is difficult to explicitly defined a traceability between this document and stakeholders requirements. I consider more the SRS in midway between stakeholders requirement and a real System specification, I will put it in parallel of Cenelec and User stories.
  • I think validation are missing in fig 1 and 2: lots of requirements can not be derived up to SW code only, but will be link to the different test or V&V phases.

§1.2 and Fig4 , It is necessary to clarify the data dictionary model and how it is defined (textual, SysML, Scade ?) as a Scade representation of it is one of the SW model.

-§2.2.1:

  • Please give clearly definition of the mining of the different arrows (for example "refines" seems to correspond to a SysML definition which is very different from a classical formal definition of "refines").
  • why "Documentation" is an activity ?
  • why "V&V" do not "use" the requirement database ?
  • meaning of the arrows are not clear for me, so I do not understand why there are no linked between System model and requirement database or functional model and requirement data base. The figure need some comments as it is not self-sufficient for those who are not used of these notations.

§2.2.2: This means we consider only functional requirements. User stories, SRS, API or Cenelec are far to contain only functional requirements.

Fig 7 : I do not think that the "openETCS system designer" is in charge of all the actions. Typically "trace model element to SRS" is made by SW designer, "Create verification view" by a verificator....

§1 and 2 : Maybe it will be nice to have a look on QA plan (WP1 https://github.com/openETCS/governance/blob/master/QA%20Plan/D1.3.1_QA_Plan.pdf), definition plan (WP2 https://github.com/openETCS/requirements) and safety plan (WP4 https://github.com/openETCS/validation/tree/master/Reports/D4.2) to have a better view of what would be expected at the beginning of the project.

§3 Ok for me.

-§4.2.3, for the moment the tool is Scade studio (v16.2)

§5, in the view of the openETCS toolchain, totally open, I am agree with the left branch (ProR linked to papyrus). However in practice the sysML model has been made with Scade system which contains an old version of papyrus not really compatible with the one in openETCS toolchain. In this case I'am not sure that ProR can be used at system level (which do not allow us to have an open-source tool for traceability !)

§ 5.1.2: How is identify the first sentence "If the establishment....." ? Are we sure that we shall always share such a requirement in different sub requirements with different Id ? Are we not going to lost information (for example in this case that ALL the sequence of actions shall be made in a given order) ?

§5, 6 and 7: Three solutions are proposed: -why ? maybe an introduction in the document is missing to explain its contents and why 3 solutions are proposed

some parts of some solutions are already implemented or largely analyzed (eg. link between ProR and payprus, use of genDoc...) other seems just propositions. It will be nice to have a clear view of what exists and can be used right now, and other elements. To continue depending updating and comments.

— Reply to this email directly or view it on GitHub.

jastram commented 9 years ago

New Reviewer: @janWelte

raphaelfaudou commented 9 years ago

Does any of you know if safety requirements identified during PoC on MoRC have been registered into .ReqIF requirements files? Do we have safety requirements to trace in the current design SCADE model?

raphaelfaudou commented 9 years ago

I have just pushed a new revision of the document that now takes into account most important remarks from Marielle and can be reviewed by any partner (especially Jan).

janWelte commented 9 years ago

Review "Traceability Architecture in OpenETCS" (by Jan Welte for WP 4)

janWelte commented 9 years ago

Finally done. Thanks for the very good document, which gives a great overview and derives some valuable concepts

raphaelfaudou commented 9 years ago

Thanks for this feedback.

Le 20 nov. 2015 à 17:03, Jan Welte notifications@github.com a écrit :

Finally done. Thanks for the very good document, which gives a great overview and derives some valuable concepts

— Reply to this email directly or view it on GitHub.

raphaelfaudou commented 9 years ago

Dear all,

Complete tutorial material to use ReqCycle for traceability between requirements and SysML model (mainly for architecture verification) is available on tool chain documentation wiki:

https://github.com/openETCS/toolchain/wiki/User-Documentation#Tracing_Requirements_and_SysML_Models_with_ReqCycle

Le 20 nov. 2015 à 17:06, FAUDOU raphael raphael.faudou@samares-engineering.com a écrit :

Thanks for this feedback.

Le 20 nov. 2015 à 17:03, Jan Welte notifications@github.com a écrit :

Finally done. Thanks for the very good document, which gives a great overview and derives some valuable concepts

— Reply to this email directly or view it on GitHub.

jastram commented 9 years ago

The review has been concluded.