-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation overview #35
Comments
Looking at your GitHub profile, I assume you are new here. Welcome! If you need any help with uploading material or have other questions, please don't hesitate to contact me. I assigned myself to the issue to indicate that I will help you here. I don't want to put my e-mail here out in the open, but you should be able to get it through @jerkerdelsing or someone else you know in the Arrowhead project. If you question is of general interest you can simply write it here. |
Following actions from the meeting with the Roadmap subgroup for “Documentation overview/strategy” on November 10th, please review attached excel file and respond to me ([email protected]), or as comment to this Roadmap issue, by Monday December 6th .
Kind regards Arrowhead Documentation overview - v05.xlsx |
ISO/IEC/IEEE 42010, which standardizes the formulation of software-architectural documentations, models and languages, contains the following list of general actors. I've added my own interpretation after each actor name. 1. User. A stakeholder taking, or trying to take, advantage of the end utility of a certain entity. To that list I would also like to add (9) Researcher and (10) Architect. The former is a stakeholder involved in the analysis or development of significant entities, particularly with the ambition of facilitating attributes or use cases that cannot be realized without refining, extending or replacing those entities. The latter is someone who seeks to improve upon or extend the Arrowhead framework itself, by, for example, writing core documentation or producing architectural descriptions. |
I would like to rise the question of expanding the Design documentation into separate lines in the matrix. I think that in particular the abstract documents like SD, SysD and SoSD would be of use in requirement/design stages of the development while the concrete documents like IDD, SysDD and SoSDD will be created somewhat later in the process. The concrete documents also would benefit from some kind of feedback loop after deployment/comissioning. |
Updates and notes at meeting 2022-04-01 |
@PerOlofsson-Sinetiq This has been discussed also in: Look especially at #34 (comment). |
Need for an overview of what documentation we need for Eclipse Arrowhead, identify what the gaps are and define needed actions.
A Roadmap subgroup are to be established.
[Documentation strategy - v08.pptx](https://github.com/eclipse-arrowhead/roadmap/files/7433737/Documentation.strategy.-.v08.pptx
Arrowhead Documentation overview - v04.xlsx
)
The text was updated successfully, but these errors were encountered: