VCL Didactical Design Patterns

User Tools

Site Tools

You are here: Welcome » The VCL Patterns » Case Study » Documentation of outcomes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
patterns:case_study:documentation_of_outcomes [2020/10/02 01:59]
editor 		patterns:case_study:documentation_of_outcomes [2022/09/19 10:08] (current)
Line 4: Line 4:
 ^**Framework** |assessment/evaluation/research based (also) on the project outcomes, complex task, special requirements regarding the outcomes’ format or documentation| ^**Framework** |assessment/evaluation/research based (also) on the project outcomes, complex task, special requirements regarding the outcomes’ format or documentation|
 ^ \\ **Solution** | \\ The participants of a VCL project may receive as a part of their assignment suggestions for the task solution. While these suggestions usually provide only a general direction, it is often necessary to provide more specific information about the expected outcomes and deliverables. The level of detail will depend on the assessment, evaluation, or research based on the outcomes. There are several points that need to be taken into account when specifying the outcomes and their documentation: \\  \\ //-Object// \\ The object of the documentation is closely connected to the aims of the VCL project as well as its assessment, evaluation, and any related research. Firstly, the documentation usually contains the final result of the task solution. Because VCL projects are process oriented (i.e., not only the final result but also the solution process are in focus), it can be also relevant to ask for the documentation of the problem-solving process. This can include, e.g., documentation of decisions, documentation of procedure, documentation of project planning and controlling etc. If the group work is also in the focus of the VCL project, it can be also useful to document group interaction, such as communication, contribution, activities etc. Learning process can also be an object of documentation, e.g., in the form of leaning journal. \\  \\ //-Extent// \\ The extent of the documentation is often (explicitly or implicitly) relevant for the assessment. It is of advantage to provide the groups with information regarding the expected extent of the documentation. This helps to make the outcomes comparable and thus ensure a fair assessment. The extent can be quantified, e.g., in number of words, pages, artefacts, documents. Depending on the context it is possible to specify minimal or maximal extent of the documentation. Minimal extent gives the groups confidence in assessing their own output (how much is enough?), whereas maximal extent can serve to prevent unnecessary engagement with subtasks. \\  \\ //-Format// \\ The documentation can have different formats, such as text document, web page, prototype, model, video etc. The participants can be provided with tools for the creation of the documentation or they can be free to choose tools on their own. This decision depends on the aims of the course as well as on the intended complexity of the task 8taking into account the tool-finding or tool-learning processes). \\  \\ //-Structure// \\ The structure of the documentation can be either prescribed or left to the choice of the participants. Predefined structure increases comparability and helps to reduce the complexity of the task. Open choice supports the creativity of the participants. Predefined structure is usually connected to more exact solution suggestions and hence can lead to a significant decrease in complexity. This can be advantageous in VCL projects with a short time span. \\  \\ //-Sub-tasks and interim results// \\ The task can be divided into subtasks, helping to decrease the complexity of the project. In this case, participants may be required to submit results to the subtasks, besides submitting the final outcome as well. Requiring the submission of interim results helps to document the solution process, but also increases the documentation effort. \\  \\ //-Time// \\ The final documentation of a VCL project is typically due at the end of the project time span and has a fixed deadline. The documentation of subtasks can be either a part of the final documentation submission or its submission can also be tied to particular due dates (milestones). The use of milestones increases the structure of the VCL project and thus reduces the complexity. \\  \\ //-Feedback, reflection// \\ If the task is divided into subtasks and the documentation is submitted through the project according to set milestones, participants will benefit from receiving feedback for their submissions during the project, instead of just in the end. Especially participants who have limited experience with project work or the particular topic may feel insecure and “left alone”. There are different forms of feedback that can be used, such as instructor’s feedback, peer-to-peer feedback, expert feedback (from external experts), or even by providing an example solution.| ^ \\ **Solution** | \\ The participants of a VCL project may receive as a part of their assignment suggestions for the task solution. While these suggestions usually provide only a general direction, it is often necessary to provide more specific information about the expected outcomes and deliverables. The level of detail will depend on the assessment, evaluation, or research based on the outcomes. There are several points that need to be taken into account when specifying the outcomes and their documentation: \\  \\ //-Object// \\ The object of the documentation is closely connected to the aims of the VCL project as well as its assessment, evaluation, and any related research. Firstly, the documentation usually contains the final result of the task solution. Because VCL projects are process oriented (i.e., not only the final result but also the solution process are in focus), it can be also relevant to ask for the documentation of the problem-solving process. This can include, e.g., documentation of decisions, documentation of procedure, documentation of project planning and controlling etc. If the group work is also in the focus of the VCL project, it can be also useful to document group interaction, such as communication, contribution, activities etc. Learning process can also be an object of documentation, e.g., in the form of leaning journal. \\  \\ //-Extent// \\ The extent of the documentation is often (explicitly or implicitly) relevant for the assessment. It is of advantage to provide the groups with information regarding the expected extent of the documentation. This helps to make the outcomes comparable and thus ensure a fair assessment. The extent can be quantified, e.g., in number of words, pages, artefacts, documents. Depending on the context it is possible to specify minimal or maximal extent of the documentation. Minimal extent gives the groups confidence in assessing their own output (how much is enough?), whereas maximal extent can serve to prevent unnecessary engagement with subtasks. \\  \\ //-Format// \\ The documentation can have different formats, such as text document, web page, prototype, model, video etc. The participants can be provided with tools for the creation of the documentation or they can be free to choose tools on their own. This decision depends on the aims of the course as well as on the intended complexity of the task 8taking into account the tool-finding or tool-learning processes). \\  \\ //-Structure// \\ The structure of the documentation can be either prescribed or left to the choice of the participants. Predefined structure increases comparability and helps to reduce the complexity of the task. Open choice supports the creativity of the participants. Predefined structure is usually connected to more exact solution suggestions and hence can lead to a significant decrease in complexity. This can be advantageous in VCL projects with a short time span. \\  \\ //-Sub-tasks and interim results// \\ The task can be divided into subtasks, helping to decrease the complexity of the project. In this case, participants may be required to submit results to the subtasks, besides submitting the final outcome as well. Requiring the submission of interim results helps to document the solution process, but also increases the documentation effort. \\  \\ //-Time// \\ The final documentation of a VCL project is typically due at the end of the project time span and has a fixed deadline. The documentation of subtasks can be either a part of the final documentation submission or its submission can also be tied to particular due dates (milestones). The use of milestones increases the structure of the VCL project and thus reduces the complexity. \\  \\ //-Feedback, reflection// \\ If the task is divided into subtasks and the documentation is submitted through the project according to set milestones, participants will benefit from receiving feedback for their submissions during the project, instead of just in the end. Especially participants who have limited experience with project work or the particular topic may feel insecure and “left alone”. There are different forms of feedback that can be used, such as instructor’s feedback, peer-to-peer feedback, expert feedback (from external experts), or even by providing an example solution.|
-^**References** |[[:patterns:alignment_and_time_cycle_of_the_vcl:learning_aims_of_a_vcl_project|]] \\   \\  [[:patterns:case_study:aims_of_the_case_study|]] \\   \\  [[:patterns:rating:start|]] \\   \\  [[:patterns:alignment_and_time_cycle_of_the_vcl:evaluation_of_the_course|]] \\  |+^**References** |[[patterns:alignment_and_time_cycle_of_the_vcl:learning_objectives_of_a_vcl_project]] \\  [[:patterns:case_study:aims_of_the_case_study|]] \\  [[:patterns:rating:start|]] \\  [[:patterns:alignment_and_time_cycle_of_the_vcl:evaluation_of_the_course|]]|
  
  

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial 4.0 International
CC Attribution-Noncommercial 4.0 International Driven by DokuWiki