This shows you the differences between two versions of the page.
Next revision | Previous revisionLast revisionBoth sides next revision | ||
team_report [2014/04/03 10:57] – created scmfcl | team_report [2015/11/15 16:47] – [Marking Criteria] scmfcl | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Team Report | + | ====== Team Report ====== |
- | You must submit a team report | + | You must submit a team report |
- | The team report is marked by your supervisor and moderator independently. Before you submit the final version you should discuss the report with your supervisor to make sure both of you agree on what your project entails. The team presentation is also about the report | + | The team report is marked by your supervisor and moderator independently. Before you submit the final version you should discuss the report with your supervisor to make sure both of you agree on what your project entails. The team report |
- | The team report should be e-mailed directly to your supervisor and moderator, and you will get oral feedback during the presentation and further formal feedback via a written report returned to the group. | + | Finally, note that this is about the requirements and architecture for the project decided by that stage of the project. You can, and most likely should, adjust these as you progress. Note, however, that with the report you are prescribing what you intend to deliver at the various stages |
- | + | ||
- | Finally, note that this is about the initial | + | |
===== Structure and Contents ===== | ===== Structure and Contents ===== | ||
- | Your team report should be at most 5,000 words per team member, excluding any figures and tales. It should | + | Your team report should be at most 5,000 words per team member, excluding any figures, tables |
- | ==== Project Title ==== | + | There should be a description of detailed aims and objectives for the project, in sufficient detail to show what each member will be working on and also how all the individual contributions will work together in the end. These are statements of what you set out to achieve with your project. Try to be as specific as possible at this stage, but avoid getting into too many details that may change later. It's only the high-level results and components of your project that are relevant. Also ensure you are including a benefit and risk assessment with relevant quality factors, and a discussion of legal, social ethical and professional issues. It must further contain a description of the software development process the team wishes to adopt. |
- | The title of the team report document should be "Team Report" | + | ==== Frontmatter ==== |
- | ==== Project Description ==== | + | The title of the team report document should be "Team Report" |
- | The first section of the document should be a brief description of your project outlining the problem you are trying to solve, its context, and overall aims. You can adapt the proposal used to select your project. Half a page to one page should be sufficient for this. | + | < |
+ | Declaration | ||
- | ==== Project Aims and Objectives ==== | + | By submitting this report each of its authors are accepting the terms of |
+ | the following declaration. | ||
- | The second section | + | I hereby declare that my contribution to this document is all my own work, |
+ | that it has not previously been submitted for assessment and that I have | ||
+ | not knowingly allowed it to be copied by another student. I understand | ||
+ | that deceiving or attempting to deceive examiners by passing off the work | ||
+ | of another writer, as one’s own is plagiarism. I also understand that | ||
+ | plagiarising another’s work or knowingly allowing another student to | ||
+ | plagiarise from my work is against | ||
+ | doing so will result in loss of marks and possible disciplinary | ||
+ | proceedings. | ||
+ | </ | ||
+ | |||
+ | Ensure that every author has seen the final document | ||
+ | |||
+ | ==== Project Initiation Documentation ==== | ||
+ | |||
+ | Provide | ||
+ | |||
+ | The project initiation documentation should be tailored to the specific project and its context. While in general it discusses the project goals, scope, project organisation, | ||
+ | |||
+ | ==== Requirements Specification ==== | ||
+ | |||
+ | You must provide a complete set of project requirements. Make sure you select and justify the approach | ||
+ | |||
+ | ==== Software Architecture ==== | ||
+ | |||
+ | Design a model of the high level software architecture to show the main components, interactions, | ||
==== Work Plan ==== | ==== Work Plan ==== | ||
- | The last section of your initial plan should consist of a time plan stating what you are working on when. This should | + | The team report must contain |
- | Make sure you clearly describe what you intend to include in the deliverables required for your project type, i.e. state what you will produce for the interim | + | Your time plan should further have at least two scheduled individual review meetings with your supervisor. You should typically see your supervisor once a week for a shorter time or once every two weeks for a longer time. The details of these arrangements are for you to agree with your supervisor. Initially this will have to be between |
- | Your time plan should further have at least two scheduled review meetings with your supervisor. You should typically see your supervisor once a week for a shorter time or once every two weeks for a longer time. The details of these arrangements are for you to agree with your supervisor. However, in your time plan you should mark out special meetings with your supervisor where you are reviewing your progress since the last such meeting (or from the beginning) and adjust your plan for the project based on the outcome of this meeting. These review meetings are mandatory and are considered as part of the mark of the reports (see marking criteria there). | + | In your time plan you should mark special meetings with your supervisor where you are reviewing your progress since the last such meeting (or from the beginning) and adjust your plan for the project based on the outcome of this meeting. These review meetings are mandatory and are considered as part of the mark of the reports (see marking criteria there). |
- | You are free to choose the work plan format that you think is best suited for your project and working style. This //may// be a [[wp> | + | You are free to choose the work plan format that you think is best suited for your project and working style. This //may// be a [[wp> |
- | description when you develop the work plan and also consider any other commitments and busy times such as the exam periods. | + | |
===== Marking Criteria ===== | ===== Marking Criteria ===== | ||
Your supervisor and moderator will mark your plan according to the following criteria: | Your supervisor and moderator will mark your plan according to the following criteria: | ||
- | * Title and project description | + | * Project initiation documentation (20%): |
- | * Aims and objectives | + | * Clarity |
- | * Time plan is feasible, sufficiently specific | + | * Suitability and justification of project |
- | * Deliverables for the reports required for your project are suitable | + | * Quality of discussion of associated risks and how these will be mitigated |
- | * Approximate | + | * Level of understanding, |
- | * The amount | + | * Effectiveness of communication and suggested methods |
- | * The report | + | * Requirements Specification (20%): |
- | on the following scale: | + | * Coherency |
- | * 0 marks: No suitable plan has been submitted. | + | * Testable acceptance criteria |
- | * 1 mark: Only a partial plan with major deficiencies/ | + | * Identification of system scope and boundaries with clear declaration of any assumptions made. |
- | * 2 marks: A plan with a project description, aims and objectives, and time plan has been submitted... | + | * Software architecture (20%): |
- | * 3 marks: ...which is feasible to execute within the constraints of the project... | + | * Quality of documentation of main components, interactions, |
- | * 4 marks: ...and has sufficient project-specific details and clear milestones... | + | * Level of detail sufficient to progress with individual projects without over-constraining them by unnecessary detail |
- | * 5 marks: ...and shows originality | + | * Quality and suitability of software architecture adopting core concepts and principles of good software design relating to decomposition, |
- | Supervisor and moderator will leave comments | + | * Level of alignment of individual team members' |
+ | * Work plan (20%): | ||
+ | * Quality of work plan, feasibility and specificity | ||
+ | * Clarity of timeline and milestones | ||
+ | * Suitability of deliverables | ||
+ | * Suitability of meeting schedule and approximate | ||
+ | * Amount | ||
+ | * Communication skills (20%): | ||
+ | * Quality of report | ||
+ | * Clarity of expression without going into unnecessary detail | ||
+ | * Frontmatter contains all required information and the declaration | ||
+ | |||
+ | All main criteria carry the weight as indicated above for the mark of the team report and will be evaluated | ||
+ | * **70 - 100% - Excellent** (rigorous, methodical, analytic, content meets all requirements of the work, very few errors or omissions) | ||
+ | * **60 - 60% - Good** (competent, reasoned, coherent, content very sound, few errors/omissions) | ||
+ | * **50 - 59% - Fair** (satisfactory, relevant, content meets many of the required elements, some errors | ||
+ | * **40 - 49% - Bare Pass** (Passable, basic relevant content, weaknesses in execution errors or omissions) | ||
+ | * **1 - 39% - Fail** (not passable, evident weaknesses, gaps in content, evident errors or omissions) | ||
+ | * **0%** indicates that the team has **not at all covered** the topic or addressed the issue. | ||
+ | Supervisor | ||
+ | |||
+ | Supervisor and moderator will provide formal feedback | ||
+ | |||
+ | Team Report coursework instructions: |