Difference between revisions of "Inter-Organizational Workflow"
Line 15: | Line 15: | ||
# 6 weeks of project time. | # 6 weeks of project time. | ||
}} | }} | ||
<section begin=TLA Logic Model /> | <section begin=TLA Logic Model /> | ||
Line 48: | Line 40: | ||
# Finish within 1 week of time | # Finish within 1 week of time | ||
}} | }} | ||
<section end=TLA Logic Model /> | |||
== Jenkins Sub-Model == | == Jenkins Sub-Model == | ||
Line 75: | Line 65: | ||
# Finish within 1 week of time | # Finish within 1 week of time | ||
}} | }} | ||
== [[Docker Workflow]]== | == [[Docker Workflow]]== | ||
Line 130: | Line 118: | ||
# [[All activities|Activities]] | # [[All activities|Activities]] | ||
# [[PKC Workflow/Drafts]] | # [[PKC Workflow/Drafts]] | ||
== 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. | |||
==Reference== | ==Reference== |
Revision as of 14:57, 25 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 |
|
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
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.