Either use handy marking and tracking template to keep track of your pupils or provide them with a copy for their self-marking of progress. This particular document is geared towards OCR but will mostly work for other boards, too.
So, how do you manage your A level pupils' projects?
Here are the top 10 tips...
Without a healthy longish list of objectives and success criteria it is impossible to do enough testing and coding to impress moderators. A project with a small list of objectives is unlikely to score well.
Pupils will require knowledge top-up sessions, they will have gaps do things inefficiently which is a particular problem when modifying their program later t=hey need to make the same changes hundreds of times over. And if that is the case, "Find and replace" is very handy.
Cover page, a table of contents and a bilbiography done in an accepted style - these are a given and need to be practiced, perhaps, with mini assignments. Don't assume that all of your pupils know how to use styles to create Table of Contents or how to fit large sreenshots to a printage page, without things moving around and diagrams breaking down.
A computing project, either at GCSE or A level is one of the hardest things your pupils have done in their academic life. So, the sheer weight of expectations might turn some of them off. So, you need to break it down in manageable chunks, at least 10 chunks with a deadline and responsibility for each one. An A level project can be rought broken into the marking scheme parts, e.g. Analysis, Design, etc and each of these needs to be broken into at least 3 sub-parts. Essentially, every sentence in the marking scheme becomes a chunk with a deadline. For example, if the marking scheme for Design mentions the requirements of pupils implementing interface design, pseudocode design, list of variables and procedures/functions, test data, etc - each of these would get is own deadline, perhaps, spaced apart by a couple of weeks.
What to do if a deadline has been breached? The danger here is the snowballing of problems once the breached deadlines delay everything else. You know you have problems when a pupil starts skipping school to catch up on work. This is not fair on other subjects and their pupil life in general! What we have found that worked, is getting parents onboard even before the school year begins. Enlist cooperation of somebody on your SMT and send a letter out to the parents about the deadlines and the importance of sticking to them. Then, if the chunk of work is not submitted on time, after a couple of days grace, the pre-agreed measures will kick in, e.g. mandatory after school or weekend attendance. It will increase a teacher's workload (although most schools' SMT run some kind of a weekend detention) but once the seriousness is demonstrated, it won't be needed that much.
Look out for the signes things are not going well for a pupil
They never have any questions for you, either in programming or in write-up.
Their computer is constantly broken, updating or in repairs, so they can't show you their project.
Pupils will underestimate what's needed to do a good job, so constant monitoring is a must. Regular interviews will make sure they are on track.
Don't spend any time on coursework in regular lessons. In A level, coursework is pretty much an independent project, you just don't have the time in lessons to give over to them coding, theory is worth much more! Also, from our experience, pupils get very little done in a coursework lesson, it's just a fact.
Extract additional evaluation marks by recommending pupils always try to think of more than one way of doing something, e.g. nested selection vs Boolean operators in a selection condition, and then explain why one way is superior.
Look for annotations in code, the code not annotated could have been lifted somewhere from Internet or off a friend - trouble!
Using the so-called Hungarian notation is a great time-saver. In Hungarian notation, variable names must include their data type, so that int_result is clearly an integer and flt_result is a float. Pupils will change their mind as the project develops and change their data type which will break some of the earlier code that used to work. They might not always be able to make that connection and waste too much time, even though it's quite avoidable. The usage of "x" and "y" is a bad practice, although using "i" and "j" for counters is an industry standard, although I find in coursework the code will contain multiple nested loops which almost always refer to either rows/records of data and/or columns, so it is better to just call them that, not FOR i=0 TO 100 but FOR row_count=0 TO 100.
If pupils are doing it in Python, look at this great post in Medium.