Difference between revisions of "Clear Up Questions/alx"

From Open Pattern Repository for Online Learning Systems
Jump to navigation Jump to search
(Created pattern in alx)
 
(Added category)
 
(3 intermediate revisions by the same user not shown)
Line 4: Line 4:
{{Infobox_designpattern
{{Infobox_designpattern
|image= <!-- Provide the filename of the image to be displayed (e.g., Design_pattern.png) -->
|image= <!-- Provide the filename of the image to be displayed (e.g., Design_pattern.png) -->
|contributor=  
|contributor= [[Christian Köppe]]
|source=  Köppe (2012)<ref name="Koppe2012">Köppe, C. (2012). [http://dl.acm.org/citation.cfm?id=2831272 Learning patterns for group assignments: part 1.] In Proceedings of the 19th Conference on Pattern Languages of Programs (PLoP 2012). The Hillside Group.</ref><ref name="deCortie">Also mentioned in de Cortie, T., van Broeckhuijsen, R., Bosma, G., & Köppe, C. (2013). [http://dl.acm.org/citation.cfm?id=2725701 Learning patterns for group assignments: part 2.] In Proceedings of the 20th Conference on Pattern Languages of Programs (PLoP 2013). The Hillside Group.</ref>
|source=  Köppe (2012)<ref name="Koppe2012">Köppe, C. (2012). [http://dl.acm.org/citation.cfm?id=2831272 Learning patterns for group assignments: part 1.] In ''Proceedings of the 19th Conference on Pattern Languages of Programs (PLoP 2012)''. The Hillside Group.</ref><ref name="deCortie">Also mentioned in de Cortie, T., van Broeckhuijsen, R., Bosma, G., & Köppe, C. (2013). [http://dl.acm.org/citation.cfm?id=2725701 Learning patterns for group assignments: part 2.] In ''Proceedings of the 20th Conference on Pattern Languages of Programs (PLoP 2013).'' The Hillside Group.</ref>
|dataanalysis= <!-- If applicable, list of data analyses used for mining the pattern separated by a " , "comma -->
|dataanalysis= <!-- If applicable, list of data analyses used for mining the pattern separated by a " , "comma -->
|domain= <!-- Learning domain the design pattern belongs to (e.g., General, Math, Algebra) -->
|domain= <!-- Learning domain the design pattern belongs to (e.g., General, Math, Algebra) -->
Line 59: Line 59:
<references/>
<references/>


[[Category:Design_patterns]] <!-- List of other categories the design pattern belongs to. The syntax for linking to a category is: [[Category:<Name of category]] -->
[[Category:Design_patterns]] [[Category:Full_Pattern]] [[Category:Learning Patterns for Group Assignments]] [[Category:Traditional Classroom]]<!-- List of other categories the design pattern belongs to. The syntax for linking to a category is: [[Category:<Name of category]] -->

Latest revision as of 07:51, 15 May 2017


Clear Up Questions
Contributors Christian Köppe
Last modification May 15, 2017
Source Köppe (2012)[1][2]
Pattern formats OPR Alexandrian
Usability
Learning domain
Stakeholders


A group assignment has been given to you and some fellow students, including a description of what has to be done and what is expected from you.


***

Some — or all — parts of the assignment description are vague and not understandable. Starting the assignment under these circumstances can lead to a wrong start of the work and also lead to time loss if things are done the wrong way.


Teacher Specifics. Each teacher has her or his own way of describing and giving assignments. What seems to be clear for the teacher, does not necessarily have to for the student too.


Student Interpretation. Sometimes students have different interpretations for the same description. They don’t agree on what the teacher is asking for. It is also the case you can start working on an assignment, and only when you get into it do things become unclear or open to multiple interpretations.


Incomplete Instructions. It is possible that the teacher forgot a part in the assignment description which is important for the students to know.


Inconsistent Instructions. Even though the instructions are complete, it might be that parts of the instructions are inconsistent or conflicting.


Wrong Work Done. Doing work that is not requested by the teacher and therefore also (often) not taken into account for grading is a waste of time. Furthermore, this time is not available anymore for working on the required parts of the assignment.

***

Therefore: After the assignment is given, summarize what is clear about the assignment and try to identify what is not. Check this with all team members. If parts stay — or become — unclear, ask the teacher for clarification.


It is always better to ask than to just assume whenever there is uncertainty. Without knowing what is asked from you in an assignment, there is a high chance that what you finally deliver is not sufficient. In some cases you also can get this information from your peer students, in other cases you need to ask the teacher for clarification. Either way, it is recommended to Nominate One Communicator (Nominate One Communicator) who’s responsible for asking the teacher or other peer teams.

In some cases it is not possible to clarify all assignment aspects at one time. In that case start with clarifying these aspects first which you need for being able to start with the assignment and postpone the clarification of the other aspects to a later moment.

After all — or enough — assignment parts are clear to you, you should be able to Deliver High Quality Products (Deliver High Quality Products). Perhaps you have to Fill Knowledge Gaps (Fill Knowledge Gaps) of some group members.


In an assignment that comprised both the requirements elicitation and the development of an online banking system, two groups had to collaborate. One group played hereby the role of the customer, while the other group had to analyze the requirements and to build the system (and vice versa). It was not clear to the groups if they should test the system of the other group in their role as users or if they should test the system developed by them, as the instructional material only stated that the developed system should be tested and that a test-report is expected as part of the deliverables. After asking the teacher what exactly was expected from them, they discovered that each group had to do two tests: a system test of their own system and an acceptance test of the system of the other group, which also had to be documented in a test-report. After this clarification all students knew what to do and they were able to finish this part of the assignment as expected.



References

  1. Köppe, C. (2012). Learning patterns for group assignments: part 1. In Proceedings of the 19th Conference on Pattern Languages of Programs (PLoP 2012). The Hillside Group.
  2. Also mentioned in de Cortie, T., van Broeckhuijsen, R., Bosma, G., & Köppe, C. (2013). Learning patterns for group assignments: part 2. In Proceedings of the 20th Conference on Pattern Languages of Programs (PLoP 2013). The Hillside Group.