Commit d89c7781 authored by Benjamin Engel's avatar Benjamin Engel

Fill out UP WPs. Add initial resource overview

parent 6b895ddd
Pipeline #1428 passed with stage
in 14 seconds
......@@ -197,16 +197,6 @@ A detailed process or set of possible processes should explained how values are
An example rule of concretion could be: a rule where every named parameter space must have a parameter definition, thus assigning a parameter type. Units may also need to be considered to be logically abstract so that when values are assigned they actually hold a true meaning. Units in this way could be expressed in a: 1) parameter definition, 2) a constraint or 3) parameter space representation where the parameter name is used or referred to.
===== Interfacing with concrete scenarios from OSC 1.x
Responsible: Sandeep P.
This section will outline the one or multiple ways of interfacing concrete scenarios written in OpenSCENARIO 1.x with a scenario description in OpenSCENARIO 2.0.
Minimally, this section should elaborate in detail the set of rules to migrate a concrete scenario in OpenSCENARIO 1.x to a scenario in OpenSCENARIO 2.0. This will enable users of the previous versions to start using OpenSCENARIO 2.0 at the earliest.
Apart from the migration rules, any other interfacing forms should also be discussed and outlined. An example of such interfacing could be the ability to directly refer an OpenSCENARIO 1.x construct in an OpenSCENARIO 2.0 scenario in an appropriate way.
==== Creation of Scenarios & Scenario Workflow (from creation to maintenance of scenarios)
Responsible: Florian Bock
......@@ -215,13 +205,14 @@ As already stated, scenarios are used throughout the development process with di
The goal of defining one single workflow for the creation and usage of scenarios seems ambitious and possibly unachievable. To cover all defined use cases, this would result in a very complex process, that would be hardly usable. Nevertheless, the goal should be to cover as much use cases as possible. To do so, an iterative approach for the application within the OSC 2.0 standardization project seems reasonable.
This implies several steps:
- A review of the already defined use cases should be done to identify missing use cases, improve the description and the differentiation among themselves and finalize the list (Use cases and usage&pragmatics section of the concept document)
- Cluster/restructure the user stories/use case examples (e.g., grouping according to the feature sets)
- Cluster/restructure the user stories/use case examples (e.g., grouping according to the feature sets)
- Link all user stories/use case examples to corresponding content from the usage &
pragmatics section if possible
- Representatives for each use case should be determined to deliver insight in the background and the underlying assumptions
- Each representative should write down his or her workflow/definition in a similar way (e.g., by using the same type of diagram or template)
- Each worfklow should be reviewed by at least one reviewer to find flaws, unclear parts and missing elements
- Each workflow should be reviewed by at least one reviewer to find flaws, unclear parts and missing elements
- All workflows should be checked for duplicates (either in whole or in parts)
- All workflows should be split into atomic parts that can be separated
- A generic workflow should be created/designed based on the separated atomic parts
......@@ -231,9 +222,9 @@ communicated to the other working groups, so that they are able to fill the gaps
- Uncovered use cases should be documented with ideas, how to proceed with them
- Review and discuss key requirements and decide about a reference implementation/API/interface
Note: A requirement for all other points above is that the reusability of subelements from a scenario should be possible.
NOTE: A requirement for all other points above is that the reusability of subelements from a scenario should be possible.
The created workflow should include all lifetime phases for a scenario, from prerequesites and ideas, over the creation and modification, until the maintenance and documentation phases. This enables the user to track the scenario in its current lifetime phase and to know how to proceed.
The created workflow should include all lifetime phases for a scenario, from prerequisites and ideas, over the creation and modification, until the maintenance and documentation phases. This enables the user to track the scenario in its current lifetime phase and to know how to proceed.
As an illustration of the concept, e.g., the creation of a scenario can be done by using different methods, from manual writing, over tool-assisted (either textual or graphical) creation to extraction or generation out of a predefined data pool. All those ways should be covered within the defined process.
......
......@@ -179,20 +179,21 @@ This WP will address the ability of adding and removing entities for the standar
.UP-ScenarioAbstractionConcretization
[cols="1,5",caption='WP {counter:wp1}: ']
|===
| *Description* |
| *Description* | Concretization or Concretion processes should explain and define reasons for why an abstract scenario intentionally does not define all dimensions and values (i.e. so they can later be optimized or explained by a supporting ODD to be made concrete.)
| *Responsibles* |
| *Deliverable* |
| *Effort* |
| *Deliverable* | Documentation & guidelines on transitioning between different degrees of scenario abstraction. Requirements to Language Concepts WPs.
| *Effort* | 50
| *Service Provider* |
|===
.UP-SuccessCriteria
[cols="1,5",caption='WP {counter:wp1}: ']
|===
| *Description* |
| *Description* | This WP will supply usage guidelines and approaches for specifying success and measurement criteria to evaluate scenarios.
| *Responsibles* |
| *Deliverable* |
| *Effort* |
| *Deliverable* | Guidelines & reccomendations for success criteria of various scenario types. Requirements to Language Concepts Wps.
| *Effort* | 30
| *Service Provider* |
|===
......@@ -220,14 +221,14 @@ Apart from the migration rules, any other interfacing forms should also be discu
| *Service Provider* |
|===
==== Feature Set
==== Feature Subset
.FS-FeatureSetsConcept
.FS-FeatureSubSetsConcept
[cols="1,5",caption='WP {counter:wp1}: ']
|===
|*Description* | Create a concept for partial support of the standard. If viable, propose specific feature sets and guidelines/methodology for validating them.
|*Description* | Create a concept for support of predefined feature subsets of the standard. If viable, propose specific feature subsets and guidelines/methodology for validating them.
| *Responsibles* | M. Kluge
|*Deliverable* | Concept to fragment content of the standard into clusters (features sets). Has to contain the approach on how to cluster the content (e.g. on domain model level), a first draft of viable feature sets and an idea on how to check language files for feature set compatibility. Definition and documentation of feature sets based on first draft provided by successor work package FS-FeatureSetsConcept. Might also contain the addition of new elements in the language to declare feature set compatibility. Definition, documentation and implementation of validation approach of language files against feature sets. Necessary for actual usage of usage of feature sets.
|*Deliverable* | Concept to fragment content of the standard into clusters (feature subsets). Has to contain the approach on how to cluster the content (e.g. on domain model level), a first draft of viable feature subsets and an idea on how to check language files for feature subset compatibility. Definition and documentation of feature subsets based on first draft provided by successor work package FS-FeatureSubSetsConcept. Might also contain the addition of new elements in the language to declare feature subset compatibility. Definition, documentation and implementation of validation approach of language files against feature subsets. Necessary for actual usage of feature subsets. An example for such a subset may be an OpenSCENARIO 1.0 compatible subset.
| *Effort* | 100 man-days
| *Service Provider* | Maybe language checks and possibly UML model finetuning (20%).
|===
......
......@@ -4,25 +4,26 @@
.Required work effort should be less than or equal to committed work effort + service provider contracts
[cols="2,3"]
|===
|*Committed Work Effort* |
| *Contracted to Service Providers* |
| *Required Work Effort* |
|*Committed Work Effort* | 1004
| *Contracted to Service Providers* | 150
| *Required Work Effort* | 1200
|===
==== Budget
This section details the budget required by the project to e.g. pay service providers and the funds to be provided by ASAM.
This section details the budget required by the project to e.g. pay service providers and the funds to be provided by ASAM. The limits are determined as a factor of the total required work effort.
Project Type Factor
New, major, minor or revision standard development project 0.25
Study project 0.25
Concept project 0.75
.Funds required for Service Providers
[options="header"]
|===
| Task Description | Effort| Cost (€700 / man-day)
|||
| OpenSCENARIO 2.0 set of documentation (language manual, usage guides) | 100 | 70.000 EUR
| Domain Model implementation | 50 | 35.000 EUR
|===
.Funds Provided by ASAM
[options="header"]
|===
| Amount (Euros)
|
|===
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment