CO7201 MSc Individual Project Study Guide 2019/20 Convenor: Dr John Drake (CA7201, CB7201, CC7201) Department of Informatics University of Leicester April 7, 2020 Foreword from the MSc Director The project is, for many students, the highlight of their MSc Course. So far much has been taught through courses with associated exams; in that sense it is probably been similar to your undergraduate studies (though hopefully a little bit harder and more challenging!). At the stage of reading this, you are embarking on the challenge of a large-scale full-time project, possibly for the first time in your career. Projects start with the selection of an appropriate topic, this requires thinking about what you would enjoy doing and discussion with members of staff. There are no right or wrong projects; neither are there harder or easier projects. It is important that you find something that you will enjoy doing; of course this ties in with the skills and techniques that you learnt during the taught part of your MSc programme. We endeavour to publish project topics very early, so that you have plenty of time to talk to staff members and think about this before having to commit to a choice. The bulk of the project occupies 3 months of full-time work cumulating in a written final report, and possibly some software or research results. We know that 3 months seem a long time when you set out to start on a project, especially with no predefined idea as to how you will spend this time. Rest assured that this will be quite a busy time for you; we can only encourage you not to leave things for later, thinking that the deadline is quite far away – you will find that time flies. You will see that we encourage you to be careful in planning your project and we have given you some intermediate milestones to achieve. We hope that you will find this study guide a useful resource at all stages in the project – it is meant to be more than just rules and regulations: it is a guide to help you get the most out of the project, covering aspects ranging from what a project is all the way through to what individual pieces of work should be contained. Study it carefully at the onset of the project, and come back to it whenever you need some advice. We hope that this last building block towards your MSc Degree will be an enjoyable experience. 1 Contents 1 Module’s Aims, Learning Outcomes and Useful Resources 3 2 Project Phases 4 2.1 Characterisation of Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Project Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Project Organization 7 3.1 Administration and Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 The Role of the Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 The Role of the Supervisor and Second Marker . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Progression checking and Submissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Important Dates and Deliverables 9 4.1 Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Supervisor Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Preliminary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Interim Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6 Final-report Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.7 Final Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.8 Viva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 Format and Structure of Documents 14 6 Plagiarism 15 7 Feedback 16 8 Late Submission of Deliverables 16 9 Mitigating Circumstances 17 10 Notification of Illness 17 2 1 Module’s Aims, Learning Outcomes and Useful Resources The aim of this module is to demonstrate a student’s ability to undertake a substantial investigation of a technical problem and its domain, by evaluating tools and methods, and by developing a professional information technology project; also, it intends to give students the opportunity to • show individual creativity and originality; • manage their own time and their progress towards completion of the project; • analyse information from a critical point of view; • apply, where appropriate, and go beyond, where necessary, the knowledge and skills taught through- out the course; • investigate/solve new and/or intellectually demanding problems (from specification through imple- mentation and critical evaluation of results); • conduct and sustain a complex argument in a coherent and lucid fashion. Among other transferable skills, students will improve the following skills: solving practical and abstract problems, communication, writing, editing, searching/gathering/evaluating information, developing eval- uation strategies and managing time. The main learning outcomes of this module are to initiate, plan, manage and deliver a substantial information technology project. Upon successful completion of the project, students should be able to: • select suitable methods and tools for analysing a substantial problem and for developing a computer- based solution for it, within known constraints; • access, retrieve and organize information relevant to the problem under study by making use of resources such as the internet and textbooks, but also of scholarly articles published in journals and conferences; • prepare a project plan, follow it and conduct regular reviews of the plan and update it; • present a properly referenced, well-structured final report, in a format suitable for professional dissemination; • communicate effectively in a presentation environment; • perform a critical reflection of the achievements in the project after its completion. The following book describes the main elements that are involved in the development of an information technology project. It provides resources to develop the aforementioned skills: Christian W. Dawson. Projects in Computing and Information Systems: a Student’s Guide. Addison-Wesley. 2nd edition. 2009. The resources referenced through this study guide and relevant for the project are collected below. 1. Calendar: https://campus.cs.le.ac.uk/teaching/resources/CO7201/#calendar 2. SVN Local Pages: https://campus.cs.le.ac.uk/labsupport/VCS/VCS 3. MSc Course handbook: https://campus.cs.le.ac.uk/ForStudents/handbooks19/MScStudentHandbook2019-20. pdf 4. Information about plagiarism: https://campus.cs.le.ac.uk/ForStudents/plagiarism/ 5. Student Learning Centre: http://www2.le.ac.uk/offices/careers/ld 3 6. Enhancing writing: http://www2.le.ac.uk/offices/careers/ld/resources/writing/index 7. Presentation skills: http://www2.le.ac.uk/offices/careers/ld/resources/presentation/index 8. Logos of the University of Leicester: http://www.le.ac.uk/corporateid/new/logos/ Important: The University of Leicester does not allow such logos to be modified (cut, resized, reshaped, change colour etc.). Therefore, if you want to include logos in any of your documents (presentations or deliverables), do not modify them. 2 Project Phases To fulfill the requirements of the MSc degree, an individual project must be undertaken full-time by the students who passed the taught component of the MSc programme. Please refer to the MSc handbook for further details of progression rules. The project is taken full-time for a period of 12 weeks (Summer) or 13 weeks (Autumn and Spring). Students who finish the taught part of the MSc programme are expected to undertake her/his project. Students will be taking the project in one of the following three periods according to their own individual circumstances: • from October to January – for students who are returning from an industri
al placement too late for a June start. • from June to September – for students who started the previous year in October or coming back from an industrial placement. • from February to May – for students who started the previous year in January or coming back from an industrial placement. Students who have to resit several of their taught modules may be told to take the project in a period that matches the schedule of their resits. Projects are carried out under the supervision of a member of the academic staff. The project consists of the following phases: • Announcement of topics: A list of possible topics will be made available before the start of the project. For each topic, the information will include a provisional title, a short description, the name of the supervisor and a list of MSc programmes for which the topic is suitable. The student has to take a topic in the field of her/his chosen MSc course. Before selecting a topic from the list, a student should discuss its details with the corresponding supervisor. Students can propose their own topics and seek a suitable member of staff to supervise them, provided that the MSc project convenor approves the topic. The project must be clearly at post- graduate level (cf. Section 2.1). The proposal should take a similar format to the topics proposed by staff. • Topic registration: As mentioned above, there are two types of topic registration: – Staff topics: Students may choose up to four projects through the project registration system. Chosen projects should be ordered by preference, with the student’s first choice appearing first in the list of selected projects. Only two topics with the same supervisor can be chosen and at least three different supervisors. We will make every effort to ensure that you are allocated one of your choices. However, students do get allocated their fourth choice. Choose wisely! – Student proposal: A student can propose a project to a supervisor. After an agreement with a supervisor and the module convenor, the student has to give a signed registration form to his/her supervisor. In this case, students need to contact a supervisor early before the registration deadline in order to start the discussion of the project. Students should reach 4 an agreement and submit the signed proposal by the corresponding registration deadline. In this type of registration students shall not select projects through the registration system. Choosing a topic implies committing to it so that a choice cannot be changed after the deadline. Bear in mind that a topic can be allocated to a different supervisor from the one stated in the proposal. • Topic allocation: Topics are allocated to students by taking into account students’ preferences and supervisors’ availability. Students who do not discuss topics with supervisors will have lower priority in the allocation process of the corresponding topics. Being first or last to talk with a supervisor does not affect your chances of being allocated that supervisor. Supervisors’ consent to supervise you does not mean that they actually will. • Project description: A project description form has to be submitted once topics have been allocated. • Official start of the project (week 1): The student then arranges for regular meetings (usually held on a weekly basis) with her/his supervisor. Weekly meetings take place until the end of the project. • Preliminary Report (week 2): The student submits a preliminary report. • Interim report (week 6): Students submit an interim report. • Interview (week 7): An interview with the second marker takes place during week 7 and has to be arranged by the student. The student should explain what has been studied and developed until that point. During this week, a meeting with the supervisor usually does not take place. • Final Report Template (week 8/9 (Summer/Autumn and Spring)): Students submit a template of the final report. The template must include a detailed literature survey relevant to the project and a detailed outline of the final report. • Completion (week 12/13): Final report and all project materials are submitted. • Viva (week 13/14): Students give an oral presentation, show their software and answer ques- tions. Each phase is described and assessed as detailed in Section 4. Deadlines are reported on the Google calendar (1). 2.1 Characterisation of Projects This section specifies the requirements that an MSc project must have. Although a project does not need to yield substantially original results (e.g., design of a new algorithm, or state and prove new theorems), it is expected to contain some element of original work (e.g., study a known algorithm under more restrictive hypothesis, specify a new validation technique, perform a comparison among techniques or tools). The project may include the development of a substantial computer-based system, but may also be purely theoretical. A project must include practical and/or theoretical results obtained by the student and cannot be mainly a review of literature. For example, converting an application available in C++ to Java or replicating an existing network simulation experiment are unacceptable topics for a project. Projects have been categorised into three main types, software development projects, technical projects and theoretical projects. Please keep in mind that these classes are not disjoint. Namely, it is possible that a project lies in the intersection of two types or all of them. The following descriptors are meant to guide the characterisation of the projects. I. Software development projects. These are projects where the main contribution is developing a significant software system. Typically, the project requires the student to use her/his creativity 5 in modelling/developing a non-trivial software system. Although a software product is the main result of projects of this type, the development process (software development tools/techniques, appropriate methodologies/architectures) is relevant. Typical challenges are that: technologies used are novel or just emerging (just being new to the student is not enough!); novel development methodologies are employed; or technologies are used in an innovative way. II. Technical projects. These are projects with an experimental flavour where the main contribution is the use/extension of existing techniques or tools for studying/analysing a substantial problem. These projects may also involve software development. However, their main focus is on the use of existing tools/techniques. Typical challenges of these projects are the complexity of the problem to study. For instance, studying the correctness of the authentication protocol Kerberos by formalising it and its properties in FDR (a CSP model checker). This project is challenging because it requires understanding how to model protocols with process algebras for verification purposes. III. Theoretical projects. Their main contribution is of theoretical nature, e.g., extending a formal modelling language, enhancing an existing algorithm and proving its time and space complexity, etc. Such projects need not include any software development. However, they require an accurate and abstract understanding on how software is designed so that strong mathematical skills are recommended. Challenges in projects of this type usually involve the interpretation of a software- related problem as a mathematical, abstract problem and the application of suitable mathematical theories and tools to solve them. For example, developing a more efficient network routing algorithm or a modelling language that allows to model new classes of software using an algebraic approach. The following examples gives a description for each class of project: I. Course Information Manager The department runs a number of modules, each convened by a member of staff. Throughout the year, certain tasks have to be conducted for managing courses. Such tasks include the generation of study guides, module forms and websites, as well as providing material on websites as the course progresses. Each of these tasks might be small, but they do tak
e a considerable amount of time. The project requires the student to develop a system that automates these tasks so that staff can manage them more efficiently. This project will make use of service oriented computing to obtain a high degree of loose coupling and extensibility. II. Model-based Testing of Service Oriented Middleware Usually, services-oriented middlewares are informally specified through textual descriptions. This leads to incomplete/ambiguous semantics that often lead to inconsistent implementations. In this project UML and graph transformation techniques are combined for modelling middleware platforms starting from their informal description. Moreover, the project requires the student to develop concepts for testing implementations of these platforms against their executable specifica- tion. As a typical use case, a core part of the BPEL4WS execution engine should be modelled with graph transformations. Such a model will then be used to test an existing Java implementation of this standard. III. Task Allocation Problem A task is an activity that an agent can perform in a finite amount of time. Given a list of tasks and a list of agents such that each agent is able to undertake each task in a finite amount of time (different agents perform the same task within different times), the problem is to find an optimal allocation of tasks to agents so that the completion of all the tasks is performed in the minimum amount of time. In this project an algorithmic solution for a task allocation problem will be developed. The specific allocation problem will be identified with the student. There are certainly various ways of tackling these problems: classic exhaustive search based on heuristics, or probabilistic approach. 6 2.2 Project Workload Working on the project is like doing a challenging full-time job for 3 months. 450 hours of self study are allocated to this module since it carries 60 credits. This corresponds to the amount of effort that has to be put in four taught modules, including private study and preparation for exams. Students should put the right amount of effort in the project from the beginning to ensure they will be able to achieve its objectives. If a student sees that (s)he is failing to spend the amount of hours needed, the student should take an action to bring her/his project back on track. Students must reside in Leicester or within easy commuting distance of the city for the development of the project. Students are required to attend lectures and practicals as specified in the module timetable (Google calendar) or as communicated by the MSc project convenor. In case of any mitigating circumstances, the normal departmental procedures should be followed and the appropriate form must be submitted. Further information about illness and mitigating circumstances is in Sections 9 and 10. Requests for absences of more than one week must be explicitly approved by the MSc Director, and will only be granted if the Department is in agreement with the proposal, and if the student concerned takes full responsibility for the completion of outstanding academic work. This procedure also applies if the absence is required for religious reasons, but as students are required to notify the Registry at the beginning of each academic year if there are likely to be religious reasons for any absence during that year, academic departments and administrative offices are expected to utilise this information pro-actively, so that any specific religious needs can be anticipated and, where practicable, met. 3 Project Organization This section describes how the project is organized/run and how students, project supervisors and the module convenor communicate. Progress monitoring mechanisms are described as well. 3.1 Administration and Communication This study guide is the main reference for the project. Students will also receive information about the project module in other ways: • The convenor may send emails on logistics (e.g., where/when lectures take place) and deadlines. • Deadlines and dates are reported on the Google calendar (1) • Supervisors give guidance and solve specific questions about the project during meetings. 3.2 The Role of the Student The project is required to be entirely the students’ own work, and it is their responsibility to ensure its quality. Students are responsible for: • Reading and understanding the study guide. • Checking University email on a regular basis. • Engaging with the project in a pro-active and reflective way, planning tasks on a regular basis and discussing ideas, queries and plans with the supervisor. • Attending meetings on a regular basis. • Meeting deadlines (consult the Google calendar and take note of the deadlines). 7 • Keeping back-up copies of all work/code/software related to the project on a regular basis by using the SVN repository as explained in Section 3.4. Important: Since the SVN repository has to be used on a regular basis, a loss of data due to your laptop being lost or stolen, a hard disk failure or similar circumstances, cannot be used as a justification for either a deadline extension or a mitigating circumstances form. Students should also actively request feedback from their supervisor on their general progress and should not feel afraid to ask whether their work on the project seems suitable for achieving the grade they are aiming for. However, supervisors are not supposed to indicate specific tasks to achieve this mark. 3.3 The Role of the Supervisor and Second Marker The project is subject to both continuous monitoring by the project supervisor and occasional monitoring by the second marker. Students will meet their supervisor on a regular basis for up to half an hour to discuss the progress of the project, starting in week 1. This meeting usually takes place on a weekly basis. The primary function of supervisors is to advise students on: • general aims and objectives of their project, • methods to be used throughout the project, • preparation of deliverables, • preparation for the Viva. Supervisors are not expected to give students instructions on how to solve problems to be undertaken in the project or to do any of their work. If the supervisor is away for more than two weeks, (s)he will make alternative arrangements for achieving a satisfactory supervision. For example, (s)he may brief a substitute supervisor (often the second marker) on the progress of the project. Should this happen, the student would be notified and (s)he would have to arrange a weekly meeting with the substitute supervisor. The second marker of the project is announced when projects are allocated. (S)he is actively involved in assisting the supervisor in assessment, feedback and advice. The second marker is involved in supervision occasionally, mainly in the interview with the second marker, as explained in Section 4.5. 3.4 Progression checking and Submissions Subversion (SVN) is an open-source revision control system. It is frequently used for safely managing code and digital resources in a distributed working environment. SVN is used to maintain files in a way that allows you to get back to earlier versions in a seamless and convenient way. The way to work with an SVN repository is to have a local copy stored on your computer (or multiple copies on all the computers you work on) and frequently commit them to the repository. Then, the committed version can be updated to all local copies of the repository. It is also possible to upload an earlier version of a file or a set of files. So it is possible to go back to a previous version of your work. More information on SVN can be found at https://campus.cs.le.ac.uk/labsupport/VCS/VCS. All deliverables will be handed in through Subversion (SVN). Students’ SVN repositories can be accessed (by the student and supervisor) from any computer, either on-campus or off-campus. Students must submit all deliverables through SVN and failure to use it may result in a Departmental Warning Letter or further action if recommendations in previous warning letters have been taken to their full extent. The usual deadline for submittin
g project deliverables is before 5pm – i.e. 16:59:59 – on the corresponding deadline, as indicated in the Google calendar (1). SVN must be mandatorily used for: 8 • Safety backup of students’ work. Students’ work-in-progress must be submitted on SVN regularly. • Storing and submitting project deliverables, and software related to the project. – Every non-trivial change should be committed separately, with a meaningful comment sum- marising the change. – An absence of commits will be interpreted as a lack of work by the student on the project. Any work must be reflected in SVN activity. • Project progression monitoring. • Retrieving and marking students’ work. Assessment will only be based on project deliverables, not on intermediate versions of documents/software. At the end of the project the following must be submitted on SVN: 1. An electronic copy of the final report in the format of the text editor that was used and a PDF version. The PDF version must be named username final report.pdf, e.g., np183 final report.pdf. All in lower case letters! 2. A copy of the source code of the software developed together with all of the following: • A setup program for installing the software. • All the code necessary for compiling and running the project. • The binaries for executing the software developed in the project, including third-party software components necessary for executing the program (provided that this is allowed by their license). • A copy of any technical documentation and/or user manual, if any. • A copy of any other project artifacts that might have been produced. • A README file that: locates the main software artifacts of the project in the repository; explains how a user can install the software from the original code; and explains how the executable itself can be run. Details like the operating system or other programs required for compilation should also be stated in the README file. Finally, before the viva an electronic copy of the presentation developed for the viva must be submitted on SVN as well. The student must submit the sources for preparing the presentation (acceptable formats are: MS PowerPoint, Keynote, Open Office, and latex) and a PDF version of the presentation. This is the only change that is allowed to the SVN repository after the project submission deadline. 4 Important Dates and Deliverables Important dates and deadlines for the project are in the Google calendar (1) Please, consult the calendar and write down the deadlines in your agenda as soon as possible. Check for updates periodically. Students progression is checked at two different levels: on a regular basis during the supervisor meeting and on certain deadlines (interviews and deliverables). The assessed elements of the project (with their respective deadlines) are: 1. Project description (pass/fail): at most one side of A4. (CB7201 12/6/2020) 2. Dedication to the project (marked: 5%): The supervisor will assess the student’s diligence and commitment to the project. 3. Preliminary report (marked: 5%): (1500 words about 4-6 pages). (CB7201 26/6/2020) 4. Interim report (unmarked): (up-to 2 pages). (CB7201 24/7/2020) Following the interim report the student will get feedback from the supervisor on progress so far and on the report itself. 9 5. Interview (pass/fail). (CB7201 27-31/7/2020) 6. Final-report Template (unmarked): a template of the final report including a complete literature survey and detailed outline of the rest of the report. (CB7201 7/8/2020) 7. Project conclusion (marked: 90%): consisting of three parts. (a) Final Report: 10000-12000 words (40-60 pages). (CB7201 4/9/2020) (b) Project core: depending on the type of project. Usually includes code on the svn repository of the student. (CB7201 4/9/2020) (c) Viva: presentation of the project in front of supervisor and second marker. (CB7201 7- 11/9/2020) All three parts are required. Failure to supply, attend, or perform satisfactorily in one of these three components could lead to the student being awarded a mark of 0 in the project conclusion. This would imply a failure in the project as a whole. The word limit excludes appendices (if any) and bibliography, but includes indexes (table of contents, table of figures) and footnotes. The final report should not exceed the upper word limit by more than 10% (13200 words); exceeding the word limit by more than 10% may result in a deduction of marks. It is our experience that final reports that are under the lower word limit by more than 10% (9000 words) have usually failed to explain important aspects of an MSc project. Short final reports are also sometimes indicative of a project where the overall achievement is not at MSc level (i.e. the student hasn’t done enough that (s)he can write about). In some unusual cases it may be the case that a good project is adequately explained in fewer than 9000 words, due to the nature of the project. You should consult your supervisor, who will advise you if your project comes into this category. Each deliverable is described in the following sections. 4.1 Project Description A project description has to be submitted through SVN after the topic allocation. The project description is a document of at most one side of A4 with the following contents: • Title of the project. • Brief description including motivation and main challenges. • Requirements of the project, classified in three categories: essential, recommended and optional. Essential requirements are both core to the project and mandatory to get a minimal working prototype. Recommended requirements are extensions to achieve a better and more complete product. Optional requirements are defined to envisage challenging features that would stretch the student’s ability to complete in the duration of the project. As feedback, your supervisor should discuss with you how realistic these requirements are and how realistic is your evaluation of the partition to essential, recommended and optional. Please note that requirements set at such an early stage of the project are likely to evolve as the project progresses and are not directly related to the grade of the project. A word document with a template for this report will be made available on the module’s homepage before the deadline. 4.2 Supervisor Meetings Starting from week 1, students should meet with their supervisor on a regular basis. 10 During a meeting, the student should: provide a summary of the outcomes from the previous meeting; discuss achievements, ideas and queries with the supervisor; propose tasks to be done during the week ahead and discuss them with the supervisor. The student should participate actively and take notes during a meeting, as necessary. 4.3 Preliminary Report By the end of week 2, students have to submit a preliminary report of 1500 words approx. (5-6 pages long). The word count of the document has to be included on the front cover. The preliminary report is a reference for the project’s aims, objectives, challenges and the time plan. The student should define/describe them by investigating background material and related work/literature. Project’s aims, objectives and challenges must be clearly stated and presented. It is also necessary to design a viable work plan, which might be updated as work progresses. The preliminary report must include: 1. a brief discussion on project relevance/motivations (why is it worth doing it?) and its main chal- lenges; 2. list of requirements, including high-level requirements or aims, and detailed requirements or objec- tives; 3. technical specifications of the project; 4. background material (including a reading list); 5. a detailed timetable and plan for achieving the objectives of the project, including the milestones of the project and a risk plan. 4.4 Interim Report By the end of week 6, students have to submit an interim report. The interim report should include a short update on the current status of the project in reference to the preliminary report. It should make it clear what parts of the requirements have been completed, started, and pending. It should also include an update
of the plan that was submitted in the preliminary report. The recommended length of this deliverable is up-to 2 pages (excluding cover page). The word count of the document has to be included on the front cover. The interim report must include: 1. A clear description of the progress that has been made with reference to the requirements that have been set in the preliminary report. 2. An update of the plan that was submitted with the preliminary report. The interim report must be submitted as a PDF file in the directory docs/3 interim report of your SVN repository. It must be named username interim report.pdf, e.g., np183 interim report.pdf. 4.5 Interview During week 7 the students will have an interview with the second marker. This interview allows students to get feedback on the project from a different point of view. The project has to be presented in a precise, informative and self-contained way. During the interview, the student will start describing the project as follows: 1. Introduction and aims of the project. 11 2. Description of the work performed until that stage. Depending on the project type, this step may cover: I. Requirements of the system, design and demo of a prototype. II. Presentation (with demo if possible) of the tools/techniques that are being used and description of experiments. III. Analysis of existing techniques, languages or theories, identification of the main problems that need to be solved, and proposed solution. 3. Main challenges and contributions. 4. Work that remains to be done and schedule. The second marker might ask questions while the student is presenting the work. There is no need to prepare slides for presentation. The interview takes place during week 7 and has to be arranged by the student. The interview usually takes place in the second marker’s office. This interview may take up to 30-45 minutes. During this week, a meeting with the supervisor is not requested. 4.6 Final-report Template A document in the format resembling the final report is to be submitted. The template consists of a detailed survey of the literature relevant to the project as well as the outline of the rest of the final report. The word count will be included in the front cover. The template must include a table of contents. Each section that will appear in the final report should be included in the template, along with the subsections. Each section/subsection should include a written sketch of the main ideas that will eventually be included in the final report. The final-report template must be submitted as a PDF file in the directory docs/4 report draft of your SVN repository. It must be named username final report template.pdf, e.g., np183 final report template.pdf. 4.7 Final Report The final report is the final and possibly the most complex among the project deliverables. The student must give a detailed account of the project in terms of • achieved results and their evaluation; • a critical comparison of the student’s work with respect to related work; • concluding remarks and a reflective analysis of the project (e.g., a discussion of non-achieved or modified objectives, and a description of possible further developments). Typically, a final report contains 10000 to 12000 words (40-60 pages). A rule of thumb is that theoretical and technical projects tend to produce shorter final reports than software development projects. Given its complexity, it is important that students prepare this deliverable carefully. A final report must be written in good English. Students must organise information in a consistent way and should use cross-references to allow the reader to easily access the document (see Section 5 for information on the format of the final report). The content and structure of the final report must be discussed with the supervisor (who will be able to guide the student to identify the structure). Generally, each final report is expected to include a description of the following aspects of the project: 1. Abstract: max 300 words describing aims, objectives and results of the project. 12 2. Introductory section: an account of aims, objectives and the original results of the project. A rule of thumb for writing a good introduction is to write it such that a reader can understand the contribution and the context of the final report without having to read it. 3. Background section: gives a thorough bibliographic account of related work. A good background section not only describes relevant work related to the project, but also tries to put the project in its appropriate context and to contrast the original approaches/methodologies/technologies proposed by the student with related approaches. 4. Contribution of the project: several sections that give details on the project results and their evaluation. For example, the structure of the body sections in the final report could be, depending on the project type: I. Requirements, Design, Implementation and Test, Evaluation. II. Problem description and problem statement, Techniques and/or Tools, Approach, Evaluation and Results. III. Problem description and problem statement, Theory, Methods, Results. For projects of type I and II, part of your contribution is the code you have written. For these projects, the contribution section must contain 3 excerpts of code that you have written yourself, with references to the files in your SVN repository where the excerpts appear. You should explain what each piece of code does. You should also state what the technical contribution of each piece of code is. For example, a piece of code that implements a complex algorithm is a bigger technical contribution than a piece of code that simply sums an array of integers. In the rare case that you cannot fulfill this requirement, you should ask your supervisor for guidance. 5. Conclusions: a critical appraisal of the project results (what has been done? does it compare to other similar proposals?). This discussion should cover aims that were part of the project but that have not been achieved (where applicable) and, in such a case, a detailed justification should be developed. The supervisor can advise on technical adequacy and style of presentation. The Student Learning Centre (http://www2.le.ac.uk/offices/careers/ld) can offer help with writing and language skills. The final report must be submitted in the format of the text editor that was used and as a PDF file in the directory docs/5 final report of your SVN repository. The PDF version must be named user- name final report.pdf, e.g., np183 final report.pdf. 4.8 Viva The main goal of the Viva is for the student to show a clear evidence of the work that has been performed in the project. The supervisor and the second marker will try to establish that whatever is claimed to be a student’s achievement in the project is actually her/his own work. As such, questions may be asked at all stages of the Viva and students will be examined thoroughly and rigorously on all aspects of the project. Students are not expected to be able to answer all questions in depth, but they should be able to provide sensible and competent responses. During the Viva, if the project involves the development of software, the student must demonstrate that the developed prototype satisfies the specification included in the final report. During the last week of the project students have to contact their supervisors to arrange the Viva if they have not been contacted already with this regard. The Viva is conducted by the student’s supervisor and second marker and has two main parts: • Formal presentation with slides (PowerPoint or similar) explaining the motivation, aims, contribu- tions and results of the project. This part will usually take 10-15 minutes. • Demo (if any) and interview with the supervisor and second marker. The structure of this second part is flexible and it is meant to be quite interactive. 13 Both parts together usually take up to 45 minutes. Attendance at a scheduled Viva is mandatory. Absence is allowed only in the light of suitable medical evidence (in which case a new Viva will be scheduled). Typically, the Viva takes place
in the student’s supervisor’s office. There is one mark for the entire conclusion of the project including the final report, project core, and Viva. It follows that performance in the Viva impacts the entire project conclusion. Failure in the Viva might result in failing the project as a whole. Notice that in some cases supervisors cannot perform the viva during the week immediately following the submission of the project. Do not make travel plans to leave Leicester before having discussed the viva date with your supervisor and second marker! 5 Format and Structure of Documents All documents that students have to deliver during the project must respect a few typographical conven- tions (summarised at the end of the section). Moreover, it is important (especially for the final report) that students take care of how the material is organised and written. Students are strongly encouraged to consult the facilities that the University of Leicester provides for improving their skills. Advices on writing, avoiding plagiarism and organising material in documents can be found at http://www2.le.ac.uk/offices/careers/ld/resources/writing/index. Moreover, it is possible find how to cite references in scientific documents at http://www2.le.ac.uk/library/help/ citing/managinginformation. The reference list should contain a mixture of books, research papers (if appropriate) and internet resources, and should not consist only (or mainly) of Internet resources. An example of a proper citation is In [1] general citation standards are presented, but the interested reader is referred to [2] for a more in depth discussion. Note that references to Internet sites should include the full URL including http, etc. These references should also include the date on which the site was accessed. Software like Zotero [3] can be useful to keep local copies of web resources and access dates. Bear in mind that, though useful, Wikipedia should not be used by itself for primary research [4]. . . . Bibliography [1] Student Learning Centre of the University of Leicester. ”’Referencing & Bibliography”. http://www.le.ac.uk/teaching/pdf/writingskills/referencingandbibliographies. pdf (accessed 10/6/2009) [2] Julia Johns, Sarah Keller. Cite it Right (1st Ed.), 2005. SourceAid, LLC. Ostervill, MA [3] Zotero website: http://www.zotero.org/ (accessed 10/12/2009). [4] Wikipedia. Researching with Wikipedia. http://en.wikipedia.org/wiki/Wikipedia: Researching_with_Wikipedia (accessed 10/9/2009) The format and structure of the documents submitted must comply with the following conventions: 1. All delivered documents must start with a title page containing the following information: (a) ”Department of Informatics, University of Leicester” (b) ”CO7201 Individual Project” (c) The full title of the project (d) The full name of the author (e) Student email and university ID 14 (f) Document name (Project Description, Preliminary Report, Interim Report, Final-report Draft, Final report) (g) Name of both the project supervisor and the second marker (h) The date of submission 2. All documents must have all pages numbered, apart from the title page. In all documents, the page immediately following the title page must contain only the abstract and the following declaration. DECLARATION All sentences or passages quoted in this report, or computer code of any form whatsoever used and/or submitted at any stages, which are taken from other people’s work have been specifically acknowledged by clear citation of the source, specifying author, work, date and page(s). Any part of my own written work, or software coding, which is substantially based upon other people’s work, is duly accompanied by clear citation of the source, specifying author, work, date and page(s). I understand that failure to do this amounts to plagiarism and will be considered grounds for failure in this module and the degree examination as a whole. Name: Date: The student must add their name in the appropriate place and date the declaration to indicate that the declaration holds for their work. Your work will not be assessed without this declaration and your final report will not be assessed until the declaration has been named and dated. The final report must be formatted on A4 paper and we recommend 12pt traditional serifed font (e.g., ”Times” or ”Bookman”) for the main text, and 10pt fixed width font (e.g., ”Courier”) for program code segments and computer outputs. 6 Plagiarism The issue of plagiarism is very important. You MUST read the University’s statement and the departmental regulations concerning plagiarism. Those can be found either in the University Regulations or on the Information for Students web pages at https://campus.cs.le.ac.uk/ForStudents/plagiarism/ You will note that the rules regarding plagiarism for project modules are different to those that apply to non-project modules. While you may certainly ask your supervisor for advice if you are having difficulties with your project, and while you may discuss your project with other students in general terms, the work you hand in must be your own. Copying other people’s work, or asking other people (e.g. via websites or similar means) to undertake work for you is a form of plagiarism, is strictly forbidden, and will result in ALL the students involved being severely penalized. It is also strictly forbidden to let people other than your supervisors have access to your work. For example, if you use a laptop to do your work, you should not lend it to anyone else while you are doing the project. In project modules it is acceptable to include quoted text written by other people, provided that the sources of information are clearly referenced in the bibliography, and are cited properly within the project report. Students must be in a position to understand such quotations, and to explain them to supervisors and examiners, especially at the time of interview and the viva voce examination. It is also acceptable to make use of software components to support the student’s own original work, but again their use must 15 be very clearly indicated, the sources must be referenced, and students must expect to be able to explain what role they play in the project. Note that according to the departmental regulations, if a student has committed gross academic dishonesty, full details of the case will be forwarded to the Registrar for con- sideration under the Code of Student Discipline. The module mark may be reduced (even to zero), which would mean that the student may not be awarded the MSc degree and that the case may constitute grounds for course termination. Any student who undertakes their studies genuinely should have no concerns, and students should understand that the role of such penalties is to try to ensure that only true and genuine effort is appropriately rewarded. Note also the declaration that you must include in all your reports and sign in your Final Report (see Section 5). 7 Feedback The department, in line with University policies, attempts to mark assessed coursework within ten working days. This policy applies to the following deliverables: Preliminary Report, Interim Report and the template of the Final Report. Students will be informed to see information about their own grades and, more importantly, about the markers feedback on their achievements. The feedback of the aforementioned assessments will be available online through the Student Feedback Webpage. Depending on the time between submission of project description and start of project feedback on project description will be given either verbally during the first meeting with the supervisor or through the Student Feedback Webpage. On the other hand, given the nature of the assessment for the project, the turnaround time for marking the final report on this module may well be more than ten working days. In this case, after all involved markers finish their marking, a moderation meeting will be carried out to guarantee assessment consistency. After the final meeting of the Board of Examiners in June (for Spring projects), in October (for Summer projects), and in Februar
y (for Autumn projects) students will be informed of the results of the degree. At this point, students may contact their supervisor for more detailed feedback on the project mark itself. The Examiners may deem a project report to be satisfactory provided that some minor amendments are made. In such a case, the Examiners may require the candidate to make the specified amendments within a specified amount of time (at most three months but usually not longer than one month). The final result will depend upon the Examiners being satisfied with the amendments that have been carried out. 8 Late Submission of Deliverables Please note that each deliverable in this module has to be handed in by a specific deadline, as reported in the Google calendar. The deadline for each deliverable is strict and no extensions are allowed. Work that is submitted late will be penalized. We need you to meet these deadlines, since it is in your interest that we keep to the prearranged timetable for the marking so that you receive constructive feedback on your progress in time. A deliverable, except for the final report, that is submitted late will get a mark of zero. In the case of late submission of the final part (including core and report) penalties will be applied according to university regulations (https://www2.le.ac.uk/offices/sas2/regulations/ documents/senatereg7-assessment.pdf). Notice that the minimal penalty is 9 points. In the event of you being unable to work on the project because of illness or other bona fide reason, allowance will be made provided that a medical certificate or other adequate documentary evidence is produced (see Sections 9 and 10). In view of the importance of handing in work on time, you need to make a conscious effort to organize your time effectively. Note in particular that when we allocate, say, two weeks for a document, we mean that it will take you two weeks (allocating the correct proportion of your time to the module) to carry out the work. You will not be able to meet the deadline if you spend one week and a half on something else and then try to do all the work in the 16 last three days. 9 Mitigating Circumstances It is the responsibility of students to inform their department(s) of any matters (whether of an academic, personal, medical or other nature) which may be relevant to their academic performance, and to supply substantiating evidence, for example, a medical certificate. Such information should be submitted be- fore the expiry of the following departmental deadlines governing the submission of evidence of special circumstances. The reporting of mitigating circumstances on time is crucial for the correct assessment of the project. Even though there are no extensions on the project, valid and timely submission of mitigating circumstances may be used to assess individual cases and spare unnecessary complications. In order for the Project Convenors and the Exam Board to consider mitigating circum- stances the relevant Mitigating Circumstances forms (MCFs) must be submitted as soon as possible and at the latest by 12 noon of the deadline for submission of template of final report and one week after the submission of the project. Appeals grounded on new mitigating circumstance unknown to the department are likely to be rejected if not supported by extremely good reasons for the delayed notification to the department. In general, the appeal panel may not be favourable to mitigating circumstances that were not reported promptly to the department. In general terms, the presentation of medical or other special circumstances does not of itself guarantee that academic concessions will be granted. Cases are considered on their merits in the light of the extent to which the adverse circumstances might reasonably be deemed to have affected a student’s performance or justified a failure to meet deadlines. The filled mitigating circumstances form has to include an evaluation of the negative effects that the circumstances had on the project and an estimation of the amount of time lost due to these circumstances. Submitted forms must be accompanied by supporting documents. 10 Notification of Illness It is students’ responsibility to make all reasonable efforts to submit all deliverables on time. In extreme circumstances, late submission may be considered as long as the last modification date of the relevant files is for the submission date (or earlier). Late submission of final report and project will be heavily penalized if not promptly justified by relevant mitigating circumstances (see Section 9). Students who suffer a minor illness lasting less than seven days during the run of the project are required to report this to the department. Students must self-certify their illness using a Mitigating Circumstances form (MCF) available at https://campus.cs.le.ac.uk/ForStudents/welfare/Welfare.html. Normally, Notification of Illness forms which are returned after the deadline for the template of the final report submission and more than one week after the submission of the project might not be consid- ered promptly (for example, for the purpose of extensions). However, all such forms will be considered at the subsequent Board of Examiners meeting. Self-certification is suspended for the project submission and the viva. Where the illness is of more than seven days’ duration or it is of a non-minor nature, medical advice should be sought and a medical certificate submitted to the Office. Students are responsible for collecting medical certificates from the Freemen’s Common Health Centre and supplying a copy to the Department. It is the responsibility of students who are required to produce medical evidence to acquire such evidence. 17 Freemen’s Common Health Centre now charges the University for providing medical certificates and reports. Students and tutors may be asked to complete an application form before a letter is written (this request form is submitted to Freemen’s Common Health Centre through the Student Welfare Service for audit purposes). Other general practices may charge for providing reports and such charges must be met by the student concerned. 18
