Stage 3: Preparing Semantic Data Specification Version Release
+Stage 3: Preparing Semantic Data Specification Version Release (on the Conceptual Model repository)
Business vi
SDS Generation substage
-In the “Initiate SDS release” business process the Development Team enables a “light” code freeze on the develop branch in order to create the SDS artefacts and review them. This code freeze only allows modifications to the conceptual model in order to fix bugs discovered during the “Dev Team internal review” and “Product Owner internal review” business processes, and no new features should be implemented.
+In the “Initiate SDS release” business process the Development Team enables a “light” code freeze on the develop branch in order to create the SDS artefacts and review them. This code freeze only allows modifications to the conceptual model in order to fix bugs discovered during the “Dev Team internal review”, "Dev Team Conceptual Model visual representation review", “Product Owner internal review (CM repository)” and "Product Owner internal review (ePO repository)" business processes, and no new features should be implemented.
@@ -333,37 +333,39 @@
-In the “Produce business view of the Conceptual Model” business process, the Development Team exports an HTML page for each folder in the Enterprise Architect (including the folder of the new ePO module) creating the “Conceptual Model visual documentation” business object on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. This is done automatically by the Enterprise Architect program. These HTML files will be reviewed by the Development Team and the Product Owner in their respective business processes later in this stage. In the next stage, “publishing candidate SDS version” the HTML pages will be integrated into GitHub OP-TED/epo-docs repository and from there published in the TED developer documentation website.
-
-
-
-
-
-
-
-Publish HTML versions in EA
-
-
-These HTML files will be reviewed by the Development Team and the Product Owner in their respective business processes later in this stage. In the next stage, “publishing candidate SDS version” the HTML pages will be integrated into OP-TED/ePO-docs repository and from there published in the TED developer documentation website.
-
-
In the “Produce the interchange format of the conceptual model” business process, the Development Team exports an .XMI file containing all the UML concepts including classes, attributes, properties, notes, etc., found in the diagrams of the Conceptual Model (editable) business object. The XMI file shall be used as an input for model2owl toolkit in order to generate the SDS artefacts. Currently the version of the XMI/UML that is being exported is 2.5.1. The XMI file is placed into the model2owl input folder on the develop branch of the GitHub OP-TED/epo-conceptual-model repository and is represented as the “Conceptual Model (exchangeable)” business Object on the workflow diagram. Once the XMI file is pushed on the repository, model2owl will automatically begin generating all the SDS artefacts. In order to simplify this artefact generation we divide it into 4 business processes:
-
+
Generate compliance checking artefacts
+
+-
+
Generate diffing artefacts
+
+-
Generate formal artefacts
-
Generate human-readable artefacts
+
+
+
+In the “Generate compliance checking artefacts” Business Process, model2owl generates the UML conventions reports for each model (represented in the diagram as the “Quality assessment reports” Business Object) on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. These reports include SHACL shape checking of the formal artefacts, and possibly other types of checks.
+
+
+In the “Generate diffing artefacts” Business Process,model2owl generates diffing reports, and change notes by comparing the current version XMI, with the latest published version of SDS. Deprecated concepts are also generated by that comparison but are contained in the Lightweight Ontology (for interoperability) Business Object. For dealing with deprecation, refer to Stage 2: Designing Conceptual Model for more information. Specifically, the following Business Objects are generated on the develop branch of the GitHub OP-TED/epo-conceptual-model repository as described in the SDS Model2owl document:
+
+
+
-
-
Generate diffing artefacts
+Change Notes
-
-
Generate compliance checking artefacts
+SDS diffing report.
-
+
In the “Generate formal artefacts” Business Process, model2owl generates the following SDS artefacts (listed as Business Objects) on the develop branch of the GitHub OP-TED/epo-conceptual-model repository for each module, using the “Conceptual Model (exchangeable)” Business Object (XMI) as input:
@@ -387,28 +389,12 @@
In the “Generate human-readable artefacts” Business Process, model2owl generates the “SDS reference document (glossaries)” Business Object, and possibly other human-readable reference documentation artefacts on the develop branch of the GitHub OP-TED/epo-conceptual-model repository.
-
-In the “Generate diffing artefacts” Business Process,model2owl generates diffing reports, and change notes by comparing the current version XMI, with the latest published version of SDS. Deprecated concepts are also generated by that comparison but are contained in the Lightweight Ontology (for interoperability) Business Object. For dealing with deprecation, refer to Stage 2: Designing Conceptual Model for more information. Specifically, the following Business Objects are generated on the develop branch of the GitHub OP-TED/epo-conceptual-model repository as described in the SDS Model2owl document:
-
-
-
--
-
Change Notes
-
--
-
SDS diffing report.
-
-
-
-
-In the “Generate compliance checking artefacts” Business Process, model2owl generates the UML conventions reports for each model (represented in the diagram as the “Quality assessment reports” Business Object) on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. These reports include SHACL shape checking of the formal artefacts, and possibly other types of checks.
-
SDS Review substage
-
+
@@ -431,16 +417,30 @@
The SDS reference documents (Glossaries).
-
-The Conceptual Model visual documentation (HTML pages).
-
The Development Team also makes sure that all GitHub Issues with a milestone of the upcoming release are implemented. If any errors or bugs are encountered, the Development Team fixes these errors by re-doing all the business processes of the Workflow from the “ORSD consolidation” Business Process, to the “Dev Team internal review” Business Process. Note that during this fixing of errors the “CM Working Group Meeting” Business Process is omitted since the changes to the Ontology are purely technical. However, if there is a problem in the conventions this might require the WG to confirm what was meant by the wrong convention to allow it to be corrected.
-In the “Product Owner internal review” Business Process, The Product Owner reviews all Objects generated in this stage for each module. Specifically:
+In the “Produce Conceptual Model visual representation” business process, the Development Team exports an HTML page for each folder in the Enterprise Architect (including the folder of the new ePO module) creating the “Conceptual Model visual representation” business object on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. This is done automatically by the Enterprise Architect program. These HTML files will be reviewed by the Development Team and the Product Owner in their respective business processes later in this stage. In the next stage, “publishing candidate SDS version” the HTML pages will be integrated into GitHub OP-TED/epo-docs repository and from there published in the TED developer documentation website.
+
+
+
+
+
+
+
+Publish HTML versions in EA
+
+
+In the "Dev Team Conceptual Model visual representation review" Business Process, the Development team reviews the "Conceptual Model visual representation" business Object. If any errors or bugs are encountered, the Development Team fixes these errors by re-doing all the business processes of the Workflow from the “ORSD consolidation” Business Process, to the “Dev Team internal review” Business Process. Note that during this fixing of errors the “CM Working Group Meeting” Business Process is omitted since the changes to the Ontology are purely technical. However, if there is a problem in the conventions this might require the WG to confirm what was meant by the wrong convention to allow it to be corrected.
+
+
+In the "Dev Team pull request to Release branch" Business Process, the Development team does a pull request in order to merge the develop branch of the GitHub OP-TED/epo-conceptual-model to the specific release branch “release/X.Y.Z” of the same repository. (for more on the creation of the“release/X.Y.Z” branch see Stage 1: Requirements Gathering)
+
+
+In the “Product Owner internal review (CM repository)” Business Process, In the context of the pull request mentioned in the "Dev Team pull request to Release branch" Business Process above, The Product Owner reviews all Objects generated in this stage for each module. Specifically:
If any errors or bugs are encountered, the Product Owner informs the Development Team, and the whole Workflow from the “ORSD consolidation” Business Process, to the current Business Process is repeated.
-If no errors are found during the “Product Owner internal review” Business Process, then the
-“Product Owner approves SDS for release” Business Process takes place. During this Process, the Product Owner communicates to the Development Team that no changes are needed in the current version of the SDS, and it can be published as a Release candidate. The Development Team subsequently merges the develop branch to the release branch of the GitHub OP-TED/epo-conceptual-model repository.
+If no errors are found during the “Product Owner internal review (CM repository)” Business Process, then the
+“Product Owner accepts pull request to release branch in the CM repository and creates a tag.” Business Process takes place. During this Process, the Product Owner communicates to the Development Team that no changes are needed in the current version of the SDS. The Product Owner also creates a tag from the release branch of the CM repository
diff --git a/epo-wf/Business Process workflow/stage4/stage4.html b/epo-wf/Business Process workflow/stage4/stage4.html
index 5f333c19d96..271198f1c3a 100644
--- a/epo-wf/Business Process workflow/stage4/stage4.html
+++ b/epo-wf/Business Process workflow/stage4/stage4.html
@@ -3,7 +3,7 @@
- Stage 4: Publishing Candidate Semantic Data Specification Version :: TED Developer Documentation
+ Stage 4: Publishing Candidate Semantic Data Specification Version(on the ePO and epo-docs repositories) :: TED Developer Documentation
@@ -286,11 +286,11 @@ eProcurement Ontology
-Stage 4: Publishing Candidate Semantic Data Specification Version
+Stage 4: Publishing Candidate Semantic Data Specification Version(on the ePO and epo-docs repositories)
-In this stage, the reviewed SDS formal artefacts are moved to the ePO repository as a release candidate and the existing SDS documentation artefacts are moved to the ePO-docs repository where the rest of the SDS documentation artefacts are generated and uploaded on the documentation website of the release candidate. The said website is also generated earlier at this stage. At the end of this stage the Product Owner invites the Wider Public to review the release candidate and decides whether or not to incorporate any feedback received to this release candidate or to a future release.
+In this stage, the reviewed SDS formal artefacts on the Conceptual Model repository are moved to the ePO repository //add link why we have different reps// to become a release candidate and the existing SDS documentation artefacts are moved to the ePO-docs repository where the rest of the SDS documentation artefacts are generated and uploaded on the documentation website of the release candidate. The said website is also generated earlier at this stage. At the end of this stage the Product Owner invites the Wider Public to review the release candidate and decides whether or not to incorporate any feedback received to this release candidate or to a future release.
@@ -350,6 +350,10 @@
After both “Mark the release candidate SDS” and “Mark the release candidate documentation” Business Processes are concluded, the “Create candidate release” Business Process is triggered. During this process the Product Owner creates a GitHub candidate release in the GitHub OP-TED/epo repository from the existent tag, using the release notes provided in the documentation repository.
SDS Generation substage
In the “Initiate SDS release” business process the Development Team enables a “light” code freeze on the develop branch in order to create the SDS artefacts and review them. This code freeze only allows modifications to the conceptual model in order to fix bugs discovered during the “Dev Team internal review” and “Product Owner internal review” business processes, and no new features should be implemented.
+In the “Initiate SDS release” business process the Development Team enables a “light” code freeze on the develop branch in order to create the SDS artefacts and review them. This code freeze only allows modifications to the conceptual model in order to fix bugs discovered during the “Dev Team internal review”, "Dev Team Conceptual Model visual representation review", “Product Owner internal review (CM repository)” and "Product Owner internal review (ePO repository)" business processes, and no new features should be implemented.
-In the “Produce business view of the Conceptual Model” business process, the Development Team exports an HTML page for each folder in the Enterprise Architect (including the folder of the new ePO module) creating the “Conceptual Model visual documentation” business object on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. This is done automatically by the Enterprise Architect program. These HTML files will be reviewed by the Development Team and the Product Owner in their respective business processes later in this stage. In the next stage, “publishing candidate SDS version” the HTML pages will be integrated into GitHub OP-TED/epo-docs repository and from there published in the TED developer documentation website.
-
Publish HTML versions in EA
-These HTML files will be reviewed by the Development Team and the Product Owner in their respective business processes later in this stage. In the next stage, “publishing candidate SDS version” the HTML pages will be integrated into OP-TED/ePO-docs repository and from there published in the TED developer documentation website.
-In the “Produce the interchange format of the conceptual model” business process, the Development Team exports an .XMI file containing all the UML concepts including classes, attributes, properties, notes, etc., found in the diagrams of the Conceptual Model (editable) business object. The XMI file shall be used as an input for model2owl toolkit in order to generate the SDS artefacts. Currently the version of the XMI/UML that is being exported is 2.5.1. The XMI file is placed into the model2owl input folder on the develop branch of the GitHub OP-TED/epo-conceptual-model repository and is represented as the “Conceptual Model (exchangeable)” business Object on the workflow diagram. Once the XMI file is pushed on the repository, model2owl will automatically begin generating all the SDS artefacts. In order to simplify this artefact generation we divide it into 4 business processes:
-
+
Generate compliance checking artefacts
+
+ -
+
Generate diffing artefacts
+
+ -
Generate formal artefacts
-
Generate human-readable artefacts
+
In the “Generate compliance checking artefacts” Business Process, model2owl generates the UML conventions reports for each model (represented in the diagram as the “Quality assessment reports” Business Object) on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. These reports include SHACL shape checking of the formal artefacts, and possibly other types of checks.
+In the “Generate diffing artefacts” Business Process,model2owl generates diffing reports, and change notes by comparing the current version XMI, with the latest published version of SDS. Deprecated concepts are also generated by that comparison but are contained in the Lightweight Ontology (for interoperability) Business Object. For dealing with deprecation, refer to Stage 2: Designing Conceptual Model for more information. Specifically, the following Business Objects are generated on the develop branch of the GitHub OP-TED/epo-conceptual-model repository as described in the SDS Model2owl document:
+-
-
Generate diffing artefacts
+Change Notes
-
-
Generate compliance checking artefacts
+SDS diffing report.
-
+
In the “Generate formal artefacts” Business Process, model2owl generates the following SDS artefacts (listed as Business Objects) on the develop branch of the GitHub OP-TED/epo-conceptual-model repository for each module, using the “Conceptual Model (exchangeable)” Business Object (XMI) as input:
@@ -387,28 +389,12 @@
In the “Generate human-readable artefacts” Business Process, model2owl generates the “SDS reference document (glossaries)” Business Object, and possibly other human-readable reference documentation artefacts on the develop branch of the GitHub OP-TED/epo-conceptual-model repository.
In the “Generate diffing artefacts” Business Process,model2owl generates diffing reports, and change notes by comparing the current version XMI, with the latest published version of SDS. Deprecated concepts are also generated by that comparison but are contained in the Lightweight Ontology (for interoperability) Business Object. For dealing with deprecation, refer to Stage 2: Designing Conceptual Model for more information. Specifically, the following Business Objects are generated on the develop branch of the GitHub OP-TED/epo-conceptual-model repository as described in the SDS Model2owl document:
--
-
-
-
Change Notes
-
- -
-
SDS diffing report.
-
-
In the “Generate compliance checking artefacts” Business Process, model2owl generates the UML conventions reports for each model (represented in the diagram as the “Quality assessment reports” Business Object) on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. These reports include SHACL shape checking of the formal artefacts, and possibly other types of checks.
-SDS Review substage
The SDS reference documents (Glossaries).
-The Conceptual Model visual documentation (HTML pages).
-The Development Team also makes sure that all GitHub Issues with a milestone of the upcoming release are implemented. If any errors or bugs are encountered, the Development Team fixes these errors by re-doing all the business processes of the Workflow from the “ORSD consolidation” Business Process, to the “Dev Team internal review” Business Process. Note that during this fixing of errors the “CM Working Group Meeting” Business Process is omitted since the changes to the Ontology are purely technical. However, if there is a problem in the conventions this might require the WG to confirm what was meant by the wrong convention to allow it to be corrected.
In the “Product Owner internal review” Business Process, The Product Owner reviews all Objects generated in this stage for each module. Specifically:
+In the “Produce Conceptual Model visual representation” business process, the Development Team exports an HTML page for each folder in the Enterprise Architect (including the folder of the new ePO module) creating the “Conceptual Model visual representation” business object on the develop branch of the GitHub OP-TED/epo-conceptual-model repository. This is done automatically by the Enterprise Architect program. These HTML files will be reviewed by the Development Team and the Product Owner in their respective business processes later in this stage. In the next stage, “publishing candidate SDS version” the HTML pages will be integrated into GitHub OP-TED/epo-docs repository and from there published in the TED developer documentation website.
+Publish HTML versions in EA
+In the "Dev Team Conceptual Model visual representation review" Business Process, the Development team reviews the "Conceptual Model visual representation" business Object. If any errors or bugs are encountered, the Development Team fixes these errors by re-doing all the business processes of the Workflow from the “ORSD consolidation” Business Process, to the “Dev Team internal review” Business Process. Note that during this fixing of errors the “CM Working Group Meeting” Business Process is omitted since the changes to the Ontology are purely technical. However, if there is a problem in the conventions this might require the WG to confirm what was meant by the wrong convention to allow it to be corrected.
+In the "Dev Team pull request to Release branch" Business Process, the Development team does a pull request in order to merge the develop branch of the GitHub OP-TED/epo-conceptual-model to the specific release branch “release/X.Y.Z” of the same repository. (for more on the creation of the“release/X.Y.Z” branch see Stage 1: Requirements Gathering)
+In the “Product Owner internal review (CM repository)” Business Process, In the context of the pull request mentioned in the "Dev Team pull request to Release branch" Business Process above, The Product Owner reviews all Objects generated in this stage for each module. Specifically:
If any errors or bugs are encountered, the Product Owner informs the Development Team, and the whole Workflow from the “ORSD consolidation” Business Process, to the current Business Process is repeated.
If no errors are found during the “Product Owner internal review” Business Process, then the
-“Product Owner approves SDS for release” Business Process takes place. During this Process, the Product Owner communicates to the Development Team that no changes are needed in the current version of the SDS, and it can be published as a Release candidate. The Development Team subsequently merges the develop branch to the release branch of the GitHub OP-TED/epo-conceptual-model repository.
If no errors are found during the “Product Owner internal review (CM repository)” Business Process, then the
+“Product Owner accepts pull request to release branch in the CM repository and creates a tag.” Business Process takes place. During this Process, the Product Owner communicates to the Development Team that no changes are needed in the current version of the SDS. The Product Owner also creates a tag from the release branch of the CM repository
Stage 4: Publishing Candidate Semantic Data Specification Version
+Stage 4: Publishing Candidate Semantic Data Specification Version(on the ePO and epo-docs repositories)
In this stage, the reviewed SDS formal artefacts are moved to the ePO repository as a release candidate and the existing SDS documentation artefacts are moved to the ePO-docs repository where the rest of the SDS documentation artefacts are generated and uploaded on the documentation website of the release candidate. The said website is also generated earlier at this stage. At the end of this stage the Product Owner invites the Wider Public to review the release candidate and decides whether or not to incorporate any feedback received to this release candidate or to a future release.
+In this stage, the reviewed SDS formal artefacts on the Conceptual Model repository are moved to the ePO repository //add link why we have different reps// to become a release candidate and the existing SDS documentation artefacts are moved to the ePO-docs repository where the rest of the SDS documentation artefacts are generated and uploaded on the documentation website of the release candidate. The said website is also generated earlier at this stage. At the end of this stage the Product Owner invites the Wider Public to review the release candidate and decides whether or not to incorporate any feedback received to this release candidate or to a future release.
After both “Mark the release candidate SDS” and “Mark the release candidate documentation” Business Processes are concluded, the “Create candidate release” Business Process is triggered. During this process the Product Owner creates a GitHub candidate release in the GitHub OP-TED/epo repository from the existent tag, using the release notes provided in the documentation repository.
ADD Merge from release to develop Business Proccess here. +The Product Owner makes sure that all The GitHub Issues are implemented for this release.
+Documentation website generation and Wider Public Review substage
diff --git a/epo-wf/GitHub repositories/githubRepositories.html b/epo-wf/GitHub repositories/githubRepositories.html index 3daf5a1f829..79f1000bd7b 100644 --- a/epo-wf/GitHub repositories/githubRepositories.html +++ b/epo-wf/GitHub repositories/githubRepositories.html @@ -359,15 +359,18 @@GitHub repositories
OP-TED/epo-conceptual-model GitHub workflow diagram
+OP-TED/ePO GitHub workflow diagram
OP-TED/epo-conceptual-model GitHub workflow diagram
+OP-TED/ePO GitHub workflow diagram