Case Study


This page describes an implementation of an assessment method by a lecturer or group of lecturers. The content of the page is the result of an interview conducted through the RAFT project in DIT in the 2013-14 Academic Year. 

[Return to Assessment Homepage]

Lecturer and Contact Details

Patricia O'Byrne

Programme and year on which assessment was offered

Description

Group case study between 3 students doing partial development of the back end of a software system.

Learning Outcomes

  • Ability to work in a group and allocate work fairly. 
  • Ability to develop a design in a group in an extended time-line.
  • Ability to develop individual code to group’s specification.
  • Ability to take the needs of other students’ software into account while developing.

What have you found are the advantages of using this form of assessment? 

  • Students get a sense of ownership over the case study
  • Students see what will and will not work in a multi-user and multi-developer system.
  • Students are expected to be able to manage their time to produce an end-result on time, with consequences for others if they do not perform.

What have you found are the dis-advantages of using this form of assessment?

 

  • Some groups will cover for a non-performing member.
  • It is challenging to come up with a different case study for each group, as class sizes grow and correction can be taxing.
  • Students can leave it all until the last day and fail.

 

Alternatives

Students can be given tighter deadlines and asked to submit pieces at different times, but this takes away some of the learning outcomes. Students could all be given the same case study, but this can lead to plagiarism.

Assessment in practice

The assessment is based on groups being given a single page description of a business requirement and developing a design. Then the individuals develop parts of it, each from the perspective of a different user.
This is suitable for lab groups of around 24 students. Lecturers / teaching assistants are required to be aware of the case studies (up to 8 per class) and the nuances of each one. While this is very successful, it requires a lot of work.

Students are assessed on the group work (design, creation of the infrastructure) and individual work (build for a specific user type) and are asked to give all students in the group a participation percentage. Lecturers / Teaching Assistants interview each group to determine what was done and who did it. They fill in a marking sheet for each group. Students also submit documentation on their work. A framework of marking ensures that students are marked fairly. Case studies have built up over the years.

Assessment Time

  • Preparation time (lecturer) : Without developing new case studies, preparation requires that students are grouped and appropriate case studies are given to each group. Groups must be published to ensure that students do the agreed case study.
  • Student time to complete: Two to three non-consecutive lab sessions and time outside labs for agreeing on designs and who does what. 
  • Marking time: Demo time – about 30 minutes per group. Marking time – review of submitted documentation.
  • Ease of Feedback: The most successful students engage with the lecturer while developing their design, but all students are given a breakdown of their marks.

Writing guidelines for staff

The development of new case studies requires that the topic will take the interest of the group and also be something to which they can relate. A sample solution should be developed in tandem with the case study scenario, to ensure that the scope of the project is adequate – neither too small nor too large. There must be enough for 3 students to do, but also it should be possible to continue if one student drops out.

[Return to Assessment Homepage]

Back to Top