Difference between revisions of "Inter-Organizational Workflow"
Jump to navigation
Jump to search
Line 19: | Line 19: | ||
== TLA Sub-Model == | == TLA Sub-Model == | ||
{{Logic Model | {{Logic Model | ||
|context= | |||
# To analyze a system correctly before it is implemented, a language to model the system and automatic tools to prove the system is required. | |||
# Mathematics is more expressive to model system and independent of the order of execution. | |||
|goal= | |||
# To efficiently state the system's preferred condition and determine them. | |||
|criteria= | |||
# The [[PKC System Specification|specified property]] are determined. | |||
|outputs= | |||
# The TLA tools are set up | |||
# The [[PKC System Result]] are shown. | |||
|process= | |||
# [[Task:TLA+ Installation]] | |||
# [[Task:PKC System Specification]] | |||
|inputs= | |||
# [[TLA+|Formal Tools]] | |||
# [[PKC System Specification]] | |||
|boundaries= | |||
# Determine what the PKC system should achieve. | |||
# Finish within 1 week of time | |||
}} | |||
{{Logic Model 2 | |||
|name=TLA Workflow | |||
|context= | |context= | ||
# To analyze a system correctly before it is implemented, a language to model the system and automatic tools to prove the system is required. | # To analyze a system correctly before it is implemented, a language to model the system and automatic tools to prove the system is required. | ||
Line 41: | Line 65: | ||
}} | }} | ||
<section end=TLA Logic Model /> | <section end=TLA Logic Model /> | ||
== Jenkins Sub-Model == | == Jenkins Sub-Model == |
Revision as of 11:23, 26 July 2021
1. Context |
| ||
2. Goal |
| ||
3. Success Criteria |
| ||
4. Boundary Conditions |
|
TLA Sub-Model
TO BE DEPRECATED: When you see this, please consider moving the logic model below from Template:Logic Model
to Template:LogicModel
1. Context |
| ||
2. Goal |
| ||
3. Success Criteria |
| ||
4. Outputs | 5. Process | 6. Inputs | |
|
|||
7. Boundary Conditions |
|
Logic Model (TLA Workflow) Template:LogicModel 07 26, 2021 | ||||||
---|---|---|---|---|---|---|
| ||||||
| ||||||
|
Jenkins Sub-Model
TO BE DEPRECATED: When you see this, please consider moving the logic model below from Template:Logic Model
to Template:LogicModel
1. Context |
| ||
2. Goal |
| ||
3. Success Criteria |
| ||
4. Outputs | 5. Process | 6. Inputs | |
|
|
| |
7. Boundary Conditions |
|
Docker Workflow
TO BE DEPRECATED: When you see this, please consider moving the logic model below from Template:Logic Model
to Template:LogicModel
1. Context |
| ||
2. Goal |
| ||
3. Success Criteria |
| ||
4. Outputs | 5. Process | 6. Inputs | |
|
|
| |
7. Boundary Conditions |
|
Ideation Sub-Model
TO BE DEPRECATED: When you see this, please consider moving the logic model below from Template:Logic Model
to Template:LogicModel
1. Context | |||
2. Goal |
| ||
3. Success Criteria |
| ||
4. Outputs | 5. Process | 6. Inputs | |
|
|||
7. Boundary Conditions |
|
- Software Resource
- Work Breakdown Structure
- Meeting and Communication
- Issue
- Updates and reports
- Documentation
- Activities
- PKC Workflow/Drafts
- Namespace Management
Notes
- When writing a logic model, one should be aware of the difference between concept and instance.
- A logic model is composed of lots of submodels. When not intending to specify the abstract part of them, one could only use Function Model.
- What is the relationship between the model submodules, and the relationships among all the subfunctions?
- Note: Sometimes, the input and process are ambiguous. For example, the Service namespace is required to achieve the goal. It might be an input or the product along the process. In general, both the input and process contain uncertainty and need a decision.