Site Tools


team_report

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
team_report [2015/09/27 16:46] – [Marking Criteria] scmfclteam_report [2022/10/06 12:02] (current) – removed scmfcl
Line 1: Line 1:
-====== Team Report ====== 
- 
-You must submit a team report covering the project initiation documentation, the requirements, software architecture and project plan in the first semester worth 15% of your total mark. The final year team project is a substantial part of your degree. It can have a major effect on the degree class you are awarded and even whether or not you pass the degree. The team report is to make sure you understand what your project requires you to do and how you are going to finish your component of the overall system developed by the team and how it links with the other team members' work. 
- 
-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 should be submitted via learning central as a single PDF document by a nominated member of your team. You will get oral feedback during the supervisor team meetings and further formal written feedback by about three weeks after submission.  
- 
-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 and how it will integrate with the other team member's work, so any change that may affect another member's work has to be discussed and agreed with the team first. In certain situations you will also have to discuss any intended changes with the supervisor to ensure they are acceptable. 
- 
-===== Structure and Contents ===== 
- 
-Your team report should be at most 5,000 words per team member, excluding any figures, tables and appendices. You are free to choose a format and structure suitable for your specific project. However, the report must address issues relating to the project initiation documentation and contain a full set of requirements with associated testable acceptance criteria, the high-level software architecture and a work plan. In particular it should state clearly the deliverables each member of the team is working on. 
- 
-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.  
- 
-==== Frontmatter ==== 
- 
-The title of the team report document should be "Team Report" followed by the title of your project. List your team members as authors with their student numbers and list your supervisor and moderator with their roles. Please also list the module number and module title you are taking and credits due for this module. Furthermore, it must contain a separate page with the following declaration, accepted by all authors: 
- 
-<code> 
-Declaration 
- 
-By submitting this report each of its authors are accepting the terms of 
-the following declaration. 
- 
-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 the University regulations and that 
-doing so will result in loss of marks and possible disciplinary 
-proceedings. 
-</code> 
- 
-Ensure that every author has seen the final document with this declaration and is aware of its implications. 
- 
-==== Project Initiation Documentation ==== 
- 
-Provide 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, but should extend it according to your findings. Following the general overview, discuss the scope of the project and specify the vision and key objectives for the project. You also have to select and justify the project management approach. Moreover, provide a risk assessment for the most significant risks and explain how these will be mitigated. This should also include managing the risks of associated legal, social ethical and professional issues. Discuss how communications will be managed within the team and with other stakeholders. You also have to select and justify the software development approach and outline the team's approach to configuration management and identify tools and techniques the team will use during implementation. 
- 
-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, business case, constraints and stakeholders, this may be different for your specific project and not all or additional issues may have to be discussed. 
- 
-==== Requirements Specification ==== 
- 
-You must provide a complete set of project requirements. Make sure you select and justify the approach to analysing the problem situation to derive the requirements. You should include associated deliverables in the appendices (e.g. transcripts of any interviews, survey results and questionnaires, process diagrams). The format/style of the requirements documentation is your team’s choice. This requirements should be presented in a format that is suitable for the selected project management / software development approach. When selecting a format, remember you are likely to do some requirements change management and version control. It needs to look professional and be understood by both developers and clients. Also provide descriptions of the most important and relevant non-functional requirements for the software with associated acceptance testing. 
- 
-==== Software Architecture ==== 
- 
-Design a model of the high level software architecture to show the main components, interactions, services and dependencies. It is important this this is sufficiently detailed to enable every team member to work on their part of the system. It should, however, avoid prescribing too many details that may unnecessarily limit the individual project work. Ensure you consider the core concepts and principles of software design for your architecture such as decomposition, abstraction, modularity, extensibility, adaptability to change and pick a suitable architecture and hierarchical relationships between the components. 
- 
-==== Work Plan ==== 
- 
-The team report must contain a high-level work plan for the remainder of the project with separate detailed plans for each team member stating what each member is working on when. This plan should be presented in a format that is suitable for the selected project management / software development approach. It should state clearly the deliverables each member of the team is working on. In particular ensure it includes clear milestones of what you expect to achieve by which date and also show how you intent to achieve these milestones and show the dependencies between the various tasks. Link the deliverables to your time plan, such that you actually plan to deliver them when they are due. 
- 
-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 the team and the supervisor. After the team report has been submitted this should then move mainly to individual meetings between team member and supervisor, with team meetings on scheduled occasionally if needed. Independent of this, the team should agree on a regular meeting scheme, as suitable for the project and its stage. While details of meetings are decided by the team and the supervisor, you should make sure everyone knows when to meet and these meeting are suitable to execute the project effectively. 
- 
-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>Gantt chart]], but sometimes other formats may be better. Usually a weekly scale for the work plan is a good choice. Also consider any other commitments and busy times such as the exam periods. 
- 
-===== Marking Criteria ===== 
- 
-Your supervisor and moderator will mark your plan according to the following criteria: 
-  * Project description with aims and objectives are clear, sufficiently detailed and provide a suitable challenge for each member of the team. 
-  * A suitable, well-justified project management and software development process has been selected with a discussion of associates risks and how these will be mitigated. 
-  * Legal, social, ethical and professional issues: Clear understanding and broader appreciation of how legal, ethical and social issues are addressed. 
-  * Team working: Quality and extent of contributions to group tasks to ensure fair distribution of workload and opportunity for originality for each team member. The ability to interact effectively with others through the use of excellent communication, via all appropriate media. 
-  * System requirements: Coherency and completeness of functional and non-functional systems requirements with clear justification/derivation. Identification of system scope and boundaries with clear declaration of any assumptions made. 
-  * Acceptance criteria: Testable acceptance criteria are associated with both the functional and non-functional requirements. Benefit and risk assessment and relevant quality factors. 
-  * Good, high-level, expandable and flexible software architecture in sufficient detail to progress with the individual projects without over-constraining them by unnecessary detail. 
-  * Integration: the individual projects of each member of the team are aligned to integrate into a complete system. 
-  * Work plan is feasible, sufficiently specific to the project, and has a clear timeline and milestones; deliverables are suitable and clearly specified for each member of the team; approximate dates for at least two review meetings per student are given; the amount of work is suitable for the credits and level of the module. 
-  * The report is well written and clearly structured. It shows clarity of expression without going into unnecessary detail. 
- 
-All criteria carry the weight as indicated above for the mark of the team report and will be evaluated on the following scale: 
-  * 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 and omissions) 
-  * 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 adequately covered the topic or addressed the issue. 
-Supervisor and moderator will mark the report independently and your overall mark for the report is the average of the two marks. 
- 
-Supervisor and moderator will provide formal feedback about your report explaining any concerns they may have and their expectations regarding the aims and objectives and deliverables. You will further get informal feedback from your supervisor in your meetings. Make sure you consider this when executing the remainder of the project. 
  
team_report.1443368782.txt.gz · Last modified: 2015/09/27 16:46 by scmfcl