Instructions to TA for Technical Audit
All groups in SEG4910 and SEG4911 will go through a hands-on audit or review of their project with the TA.
The audit is a chance for you to demonstrate to the TA how your working environment is set up for building the code, and illustrate the development processes you have put in place for your group, as well as show the system running and the organization of the underlying source code.
There is no mark assigned for the audit, but it does provide a check to confirm the information you have provided in your deliverables and presentations. If the TA notices something especially good or especially bad, it will be flagged to the attention of the Professor for the course who will investigate further. In that regard, it can influence the evaluation of the professor (which is worth 20% of the course).
Here are the instructions given to the TA, in conducting the audit or review of your projects.
1. The TA should read the milestone 2 evaluation in the case of SEG4910, and the milestone4 evaluation in the case of SEG4911, before the audit/review to ensure they are familiar with the project and the team members.
2. The TA will take attendance and ensure that all members of the group are there and make a point of ensuring that each member contributes at least one piece of information to the conversation. It is the responsibility of the TA to directly question those members who might be shy and less inclined to volunteer information in order to ensure full participation.
3. The TA will not spend a lot of time. 15 minutes per group is the target (but the TA and the group will have to be organized to get it done in 15 minutes). Bigger groups will probably take a bit longer but definitely MAXIMUM of 5 minutes per member. (E.g. the biggest group has 6 people, something is wrong if you are taking more than 30 minutes).
4. The TA should feel free to discuss things with the group and give their personal opinion. It is good for everyone and the students to have such an interaction. BUT do not get into arguments. ... if things get heated the TA should simply say "oh well we have a difference of opinion, you should just make sure you are in synch with the customer and your professor ... both of whom may have a different opinion than me" and move on. But if either group has a concern they are more than welcome to bring it to the attention of the Professor.
5. The following should be covered:
a) Real Demo
A demo that runs and a quick tour of the code. It should be related to one or more of the critical scenarios from milestone 2 or 4.
b) Roles and Individual Development Environment
An explanation of what each person’s role is, where each person tends to do their development and confirmation that each person has the complete development environment set up where they can work (this is where you should talk to each person). Everyone on the team must be capable of building the system, be familiar with all source code (able to explain it), and be able to run and explain the system.
c) Source Code Management
Description of the person and process responsible for integrating the code and ensuring it builds and runs.
d) Quality Management
Description of the person and process responsible for defining tests, running tests, and logging issues.
e) Project Management
Description of the person and process responsible for managing the project. This is the person who knows who is working on what task/deliverable and when it will be done
f) Customer Management
Description of person and process responsible for requirements and customer (business analyst). How do they know what the customer is expecting, how do they know the tests and code are addressing it, how often do they interact with customer including review of documents and running systems?
The TA does not have to go through the list above in detail. The TA can pick and choose where to dig in, but the TA should cover everything at a high level.
All the TA needs to report to the professor is:
Group:
name of group you met with
Roles:
List of members and there responsibilities: e.g.
Tom Frank, Project Manager
Jane Doe, GUI coder etc.
Assessment:
Either Excellent, Good, or Poor
Good is what is expected each group to get. Excellent or Poor are only for exceptional
cases. THIS DOES NOT TRANSLATE INTO GRADES IN ANY WAY. It is just a flag for the Professor.
Good means: everyone had a role, development environment and the team had a real demo and reasonable process set up for source code management, quality management, project management and customer management.
Excellent means: you want to highlight something especially noteworthy about the group
(give me a short explanation)
Poor means: you want to highlight something of concern that I might need to follow up on (give me a short explanation ...e.g. Tom does not think he needs a development environment since he is not coding ...)