Difference between revisions of "Logic Model"
Line 1: | Line 1: | ||
A Logic Model is a one page diagram that summarizes the Context, Goal, Desirable Effects, Input/Output Specification of a set of Activities. | A Logic Model is a one page diagram that summarizes the Context, Goal, Desirable Effects, Input/Output Specification of a set of Activities. | ||
It is also a kind of structural description of the nature of [[data]], [[function]]s, or [[logic]] in a fundamental form. All [[data]], [[logic]], [[function]]s, should be describable in a Logic Model, so that when some data item, even as simple as a number, say [[42]], had been captured in the form of Logic Model, the past experience can be reused for future references. | It is also a kind of structural description of the nature of [[data]], [[function]]s, or [[logic]] in a fundamental form. All [[data]], [[logic]], [[function]]s, should be describable in a [[Logic Model]], so that when some data item, even as simple as a number, say [[42]], had been captured in the form of Logic Model, the past experience can be reused for future references. | ||
This is an instrument for one to quickly organize thoughts and create a Design Contract with the rest of the world. | This is an instrument for one to quickly organize thoughts and create a Design Contract with the rest of the world. |
Revision as of 08:12, 28 July 2021
A Logic Model is a one page diagram that summarizes the Context, Goal, Desirable Effects, Input/Output Specification of a set of Activities.
It is also a kind of structural description of the nature of data, functions, or logic in a fundamental form. All data, logic, functions, should be describable in a Logic Model, so that when some data item, even as simple as a number, say 42, had been captured in the form of Logic Model, the past experience can be reused for future references.
This is an instrument for one to quickly organize thoughts and create a Design Contract with the rest of the world.
The syntax for filling up the Template is as two parts. The top part, surrounded by a blue dashline, is the abstract specification of a function. Describing what it is. The bottom part, surrounded by a red dashline, is the concrete implementation, revealing the resources and strategies to realize the cause-effect linkage between the abstraction specification with the concrete implementation and execution. The two parts, top and bottom of a Logic Model is shown below:
{{
Logic Model
|context=A statement describing the spatial and temporal context of the event or project at hand.
|goal= An imperative statement that describes what is to be accomplished.
|criteria= A conditional statement that can be judged based on the outputs of the expected execution process.
|outputs= A list of items that were to be created through the process.
|process= An organized set of actions or sub-processes that takes inputs and transforms them into outputs.
|inputs= A set of resources that were to be employed in the above mentioned process.
|boundaries=A set of situations which could affect the validity of the overall project, or event.
}}
A Rendered Logic Model in a PKC page
And it should be rendered in a page as what follows:
TO BE DEPRECATED: When you see this, please consider moving the logic model below from Template:Logic Model
to Template:LogicModel
1. Context |
A statement describing the spatial and temporal context of the event or project at hand. | ||
2. Goal |
An imperative statement that describes what is to be accomplished. | ||
3. Success Criteria |
A conditional statement that can be judged based on the outputs of the expected execution process. | ||
4. Outputs | 5. Process | 6. Inputs | |
A list of items that were to be created through the process. |
An organized set of actions or sub-processes that takes inputs and transforms them into outputs. |
A set of resources that were to be employed in the above mentioned process. | |
7. Boundary Conditions |
A set of situations which could affect the validity of the overall project, or event. |