Pt. 6: General Progression and Feedback (Sprints)

Pt. 6. General Progression and Feedback (Sprints).

This blog post forms a prospective reflection on the creation of digital technologies used in teaching. It is a prospective reflection, in most cases an oxymoron, because the design and creation of the materials is partially complete, but materials have not yet been delivered to students.  

The first few iterations of design have been carried out using a combination of development methodologies, picked and spliced due to the nature of the project itself.  With two analysts assigned to the project (myself and one other) and a single development officer, it was important to structure the first stages of the project using agile methodologies; this allowed for time-boxing that fit around increased workloads during the analysis and design stages.  With limited development time available for actual construction of the materials, it was/is vital that the intitial design be perfect before recording take place.

With both analysts having both delivered, and been on the end of delivery of this particular subject (and material) both have an idea of how the material will be recieved by students this coming semester.  However, no in situ testing can take place before the end of this reflection, so it was important to me to obtain further feedback from students.

To do so i approached several students that i know have recieved tuition recently, ranging from one to three years previous.  During discussion of the current, text-based ststem, all students agreed that material was dry and unimaginative; a particularly rending statement as it was myself that designed a number of the recent additions.  When proposed that some of the materials be replaces with vocal podcasts, students suggested that it would be useful to have this in addition to written transcripts, and that jolification of the materials would be a sensible way to get more involved.  Some, expectidy, enquired about whether it would be a poor attempt at comedy.

A number of the students that were questioned about the concept, were asked to read over this blog (posts 1-5), as part of the discussion.  Several of these students suggested that the blog itself form part of the teaching materials for the module in question.  This was particularly pleasing, as this was, by subterfuge, an idea that i had during the design of the blogs themselves; with the design and blogs following project management conventions itself. 

There has been great fun had designing this project, and i can see a great benefit to delivering materials in this manner.  It will allow student to have uadio description of a seminar task in advance, with, hopefully, more students approaching the materials before the discussion begins.  This is a particular problem that this module has had historically, as the delivery method has been textural, and drab.  

The project has helped me to think about delivery methods for low-level discussion, and has played upon what i see as one of my current strengths, in joining together tasks on multiple topics, in multiple formats.  These have previously been classic Lecture/Lab/Seminar links, with podcasts and blogs being an extension to this.

However i approach further projects with trepidation.  Students in the school of computing already have a range of digital technologies to navigate on the route through their degrees, and i have minor concern on adding new delivery methods to this catalog. Whilst blackboard hosted podcasts may be a suitible way to deliver official materials, the addition of official teaching through blog posts adds another channel students may be required to use, and could cause confusion about where materials are hosted.

Pt. 5: Purchase Goods and Services.

Pt. 5. Purchase Goods and Services.

Our basic requirements have been set out, and basic design initiated. Additionally a contractor has been selected in the way of an associate.

Our next stage is to aquire their services, to which end the associate was contacted, and invited to initial meetings.  Contractor resources were discussed as well as initial ideas for the project, and creative amendments were made.  It should be reiterated at this time that the selected associate specialises in this particular field of study themselves, and is familiar with the material taught on this course; so further input was discussed.

Initially the suggestion was that the analysis and design team script the material themselves, with the associate bought in to the 'organisation' as staff augmentation. However, as the meeting progressed it became clear that a total outsourcing approach would suit the project needs far better.  

In this context it was agreed that our contractor would design and implement (record) the system fully.  Given the initial spec, and creative discussion of the meeting, the associate would generate scripts, modify (after feedback) and record the dialogue.  This would not only ease time pressures on the analysis team, who have other material to generate, but also give a good measure of experience in creating teaching materials to the associate. 

Development approach

As development approaches are themselves part of the core teaching on this course, a simple agile methodology was selected (RAD).  Other agile methodologies that are discussed in the course (rapid prototyping) were deemed to be a bad fit for this project due to the nate of the product.  

Creative Discussion

During the initial contractor briefing the requirement were laid out, and contractor resources were discussed (which impressions were in their repetoire).  The following amendments were made.

The six requirements were split into two catagories, the first, on development of systems, the second on project management.

Development meterials to be created using impressions of Muppets, in a cookie factory scenario.  

1. System type case studies: Four distinct voices for different system types. The Count for Accounting systems etc.  
2. Rich-pictures: The Cookie monster (factory foreman) describing the process within the system.
3. Entity Relationships: Kermit the Frog detailing information passing around the system.
4. Development type case studies: Mixed muppets discussing issues.

Project Management meterials to use popular film characters.

1. Good-plan/Bad-plan: Bad plan script taken from 'Jingle all the way' film using an Arnie impression. Good plan as Golum in the LOTR series. Middle plan as Korg from the Avengers francise.
2. Use-case studies: Full plot of Avengers infinity-war/endgame from Korg's perspective.

Handover to Outsource Contractor

With these requirements in mind, the development details were handed over to the contractor, and fees paid.  The product is still in development at this time.

Pt. 4: Plan and Schedule

Pt. 4. Plan and Schedule

After determining that our plan of action should be to introduce materials by podcast, the two lead analysts sat down to discuss which topics were suitible for this style of delivery.  Currently, the foundation year computer science course is being restructured to remove redundancy, and bring it in line with current teaching at A-level. During this process a previously delivered module was due a moderate update, and this seems the place to intruduce soce delivery.

The two analysts targeted several areas where previous delivery, by textural description, sidestapped the intended learning outcomes. Six key areas, which remain in, or are a new part of the module, were deemed to be suitible places for introduction:

1. System type case studies: Brief descriptions of different systems required for further design and implementation
2. Rich-pictures: Traditionally a text based description of major interactions and conflicts within a system. The textural description is the intended first stage before creation of the diagram, so this is a key area that can benefit from the new design.
3. Entity Relationships: A description of the data held by and/or used within an existing system.
4. Development type case studies: Brief descriptions of different constraints within the company that might affect development methodologies.
5. Good-plan/Bad-plan: Three descriptions of project plans and why the overall progress was good/poor/failure.
6. Use-case studies: Description from a full case study, including state changes within a system.

These six 'products' were discussed with the prospective associate, who is both a proficient impressionist, and knowledgeable about the material itself.  One major topic of discussion centered around which characters to use for the project. 

And so the specification was fixed, with ongoing discussion around cosmetics.  the next step... purchase goods and services.

Pt. 3: Design

Pt. 3. Design

Given the concerns about current methods used for teaching/learning the basics of system design, it was sensible to target and approach a development team. Being rather insular at this stage, an in-house analyst was approached, and the discussion into possible development team members was opened.


Attention was quickly turned to how podcasts could be made more interesting to students, one of the projects primary stakeholders.  Being at the start of their analysis and design careers, the target students for this project are generally recent high school graduates, and specifically (at least initially) foundation year degree students; however it would be bad practise to aim material solely at this group. 

This raises the issue of course, that a man fast approaching his 40's, is unlikely to be as in tune with the interests of those in their late teens.  To this end, it was suggested early in the project, that the material delivered to students should be informal, and at least light-hearted in nature.

One of the analysis team believed that they had a solution.  To use a standard analysis interview, but with celebrity or character voices, courtesy of an impressionist.  This would allow us to keep material lighthearted, while the process, and therefore the required learning objectives, remain formalised.  Luckily, the analysis team knew a developer that is both an analyst, and an impressionist.

And so a design idea has been decided... the next step: Plan and Schedule...

Pt. 2: Analysis

Pt. 2. Analysis.

A bubbling need has been identified:  Current methods of content delivery and discovery are sub-optimal for learning.  But how can this be changed?

How do we replace this verbal interaction within the first stages of systems analysis? A common answer would be to hold faux interviews for the students; but how can this be done with 20 students in an hour or two, and still allow time for the critical discussion between seminar leaders and peers? The simple answer, it can't.  And even if you had the time, do you allow the other students to listen in on each interview? If not what do they do during the other interviews?


The obvious stakeholders were identified. Namely the students and seminars leaders at this stage, with the interests of module and course designers as secondary considerations.

We have the technology, we can re-build it!

So do we have a vector by which we can deliver this verbal discussion? Well perhaps not quite as we would like, but we can certainly approximate a real world scenario.  Whilst the learners themselves may not be able to ask detailed questions themselves, pod-casts would at least allow a verbal, pseudo real-time account of a current or desired system, allowing the learner to be a 'fly on the wall' and create notes on the problem.

And so a solution has been conceived... the next step: Design...

Pt. 1: Inception

Blog 1

I have been studying at UEA since 2001, when I started a degree in Computer Systems Engineering.  After dropping out after the first year I returned in 2006 to study on an Applied Computing degree, seeing it as better suited to both my learning style and engagement issues. 

After finishing my studies I returned to continue studying at Ph.D level, and immediately started teaching in computing science, and continued beyond my Ph.D: becoming a full time tutor in 2016, an being appointed lecturer in 2018.  

My Current teaching portfolio includes multiple modules at all levels within computing science (foundation year to masters year). Teaching on ten modules this academic year, I consider myself to be a generalist, rather than a specialist. However most of my teaching focus surrounds practical programming and systems development, with additions of electronics and modern embedded technologies.  Notably, my one specialism, Computer Vision (the context for my Ph.D) is a subject that I have very little interaction with.

The students I teach vary wildly in background and technical literacy. I regularly teach students with zero background in the topic, or even in the scientific field.  At the other end of the scale I teach students with a standing degrees in technological subjects. As an example of the scope of this, one of my students recently stated that their only previous experience of using a computer, was to watch YouTube; whilst another student in the same class had over a decades experience in software development.

Teaching on so many subjects, over so many academic years and backgrounds, I favour a strong constructivist approach (J. Biggs & Moore, 1993; Mezirow, 1991). With such scope of teaching this allows me to reference other key learning from a degree, as well as frame learning within the students' future studies.

In the last few years I have introduced Padlet on a number of modules in my portfolio.  This has shown significant benefit onto more advanced level modules, where the material is delivered at high pace, assuming a certain level of knowledge from previous study.  This has allowed students that have perhaps not absorbed materials in previous years, to ask questions of the lecturer in real time, and anonymously. This has had the knock on effect that students can query points between taught sessions, receiving feedback from the lecturer, ATs and their peers (Keppell, 2008).

References

Biggs, J., & Moore, P. (1993). The process of learning 3rd. ed. Australia: Prentice Hall.

Mezirow, J. (1991). Transformative dimensions of adult learning: ERIC.

Henning, J. M., Weidner, T. G., & Marty, M. C. (2008). Peer assisted learning in clinical education: Literature review. Athletic Training Education Journal, 3(3), 84-90.