Site Tools

Trace:
individual_report

Differences

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

Link to this comparison view

Next revision		Previous revision
Last revisionBoth sides next revision
individual_report [2014/04/03 10:41] – created scmfclindividual_report [2015/11/15 16:52] – scmfcl
Line 1: Line 1:
-====== Individual Report (software engineering project) ======+====== Individual Report Guide ======
  
-You  must submit an individual report worth 75% of the total project mark, which should cover the overall project background, approach, findings and achievements of your part of the project. You will also have to submit a complete set of the deliverables that you developed for the project including any source code and soft system models). This involves the development of some tangible piece of software and/or hardware, possibly with system designs and/or theoretical results. It need not necessarily be a usable finished product. Instead it could be, for example, an extension to an existing system or a prototype built as part of a feasibility study. This must be submitted towards the end of the second semester. See your project details in PATS for the submission deadline. +You must each submit an individual report at the end of the second semester worth 75% of your total mark. You will also have to submit a complete set of the deliverables that you developed for your part of the project including any models, test cases and source code. The individual report is marked by your supervisor and moderator. 
- +
-Please see your initial team report in which your group should have clearly outlined the deliverables for your individual report. Your supervisor and/or moderator may have left additional comments on this report on PATS to tell you whether these deliverables are suitable and what they expect for the individual reports. Check the comments on PATS for your report. Your deliverables may be adjusted based on your findings since the team report. If so, justify this in the report. Also discuss carefully with your supervisor what you should be including in the indvidiaul report.+
  
 ===== Structure and Contents ===== ===== Structure and Contents =====
  
-The final report should be at most 20,000 words long. General guidance on project report structures is available in [[Arranging Material and Structuring the Project Report]]. A possible structure for your final report is: +We would expect the main body of the final report to be approximately 12,000 – 15,000 words and should not exceed 20,000 words. This report builds on the team report. The report should not repeat the contents of the team report, but may refer to it and expand on it. The report should include:  
-|  |Title Page            |Support  | +  * an introduction to the project including a summary of your agreed individual responsibilities;  
-|  |Abstract              |:::      | +detailed design and any further analysis of the problem specifically relating to your part of the project; 
-|  |Acknowledgements      |:::      | +  * a discussion of the development of your part of the project covering implementation and how this integrates with the rest of the team;  
-|  |Table of Contents     |:::      | +  * discussion of the testing used at a team and individual level, e.g. validation, unit testing, integration and systems testing; 
-|  |Table of Figures      |:::      | +  * an evaluation of the product and process at a team and individual level;  
-|1.|Introduction          |Main body| +an analysis of  the team dynamics and a reflection on what you have personally learnt from carrying out the project; 
-|2.|Background            |:::      | +  * conclusions and future work. 
-|3.|Approach              |:::      | + 
-|4.|Implementation        |:::      | +A possible structure for your final report is:  
-|5.|Results and Evaluation|:::      | + 
-|6.|Future Work           |:::      | +  * Title Page  
-|7.|Conclusions           |:::      | +  * Abstract  
-|8.|Reflection on Learning|:::      | +  * Acknowledgements  
-|  |Glossary              |Support  | +  * Table of Contents  
-|  |Table of Abbreviations|:::      | +  - Introduction  
-|  |Appendices            |:::      | +  - Detailed analysis and design   
-|  |References            |:::      | +  - Implementation 
-If you are implementing a piece of software the “Approach” section above would be the “Specification and Design”. For a project addressing a “softer” problem the Approach section may be “Selection of Approach”. If instead you intend to compare algorithms it may be “Alternative Designs and Final Algorithm" and if you intend to design and and analyse an algorithm it could be “Algorithm Designs”.+  - Testing 
 +  - Evaluation 
 +  - Reflection 
 +  - Future Work and Conclusions 
 +  * References  
 +  * Appendices  
 + 
 +===== Main Body of the Report ===== 
 + 
 +Each of the sections of the main body of the individual report are discussed in more detail below. You can use this characteristic structure as a rough template for organising the material. However, often it may be of advantage to adjust the suggested structure to your particular project instead of sticking to the template. Consult your supervisor for advice. It is also a good idea to plan roughly how long each part should be before writing the report, to make sure that the length and overall balance are about right. You can then construct each part to produce a first draft of the main body.  
 + 
 +===== The "Introduction" ===== 
 + 
 +The Introduction should relate the student’s individual contribution to the team report and discuss any changes, extensions or new insights. It should outline the suitability, scope, and originality of your part of the system. It should also provide a summary of your agreed individual responsibilities. 
 + 
 +===== The "Detailed Analysis and Design" ===== 
 + 
 +The purpose of this section is to provide information on the detailed analysis and design of YOUR PART OF THE SYSTEM that has been done since the team report. This section may describe such things as:  
 +  * the problems and challenges  that has been identified, 
 +  * research and/or further analysis to fully understand the problem area 
 +  * any constraints on the approach to be adopted, 
 +  * existing solutions relevant to the problem area, and why these are unsuitable or insufficient in this particular case, 
 +  * any further methods and tools (not discussed in the team report) that your part of the solution may be based on or use to solve the problem, 
 +  * consideration of legal/ethical/professional/social issues 
 + 
 +Long descriptions of details are to be avoided and references to suitable sources of detailed information should be given instead.  
 + 
 +Possible viewpoints of the design might discuss:  
 +  * the business model the software supports, 
 +  * the user interface, 
 +  * the dynamic behaviour of the system, 
 +  * what data types are implemented in the system, 
 +  * what algorithms are implemented in the system, 
 +  * the static architecture of the system, i.e. how the code is partitioned into modules, etc. 
 + 
 +Fine details, specifically details of code, should be left out. We strongly recommend that you make extensive use of diagrams, such as entity-relationship diagrams, UML diagrams, state charts, or other pictorial techniques.  
 + 
 +As well as describing the system, it is important that you justify its design, for example, by discussing the implications of constraints on your solution and different design choices, and then giving reasons for making the choices you did. Typically these implications will relate to the aims of the project; to the relevant functional and non-functional requirements specified in the Team Report and to any innovative aspects of your design. 
 + 
 +The design of the system will almost certainly have evolved while you were developing it. Obviously you should describe its final state but often there are good reasons for describing intermediate states, too; for example, if you want to discuss the details of the design method used or to highlight learning that you later refer to in the Reflection section. If you do this, take special care to make sure the reader does not get confused between different stages of the design.  
 + 
 +===== The "Implementation" ===== 
 + 
 +The Implementation section is similar to the previous section in that it describes the system, but it does so at a finer level of detail, down to the code level. It can also describe any problems that may have arisen during implementation and how you dealt with them.  
 + 
 +Do not attempt to describe all of your code in the system, and do not include large pieces of code in this section. A complete listing of your source code should be provided separately in the appendices. Instead pick out and describe just the pieces of code which, for example:  
 +  * are especially critical to the operation of the system; 
 +  * you feel might be of particular interest to the reader for some reason; 
 +  * illustrate a non-standard or innovative way of implementing functionality 
 + 
 +You should also mention any unforeseen problems you encountered when implementing and integrating your part of the system with the work of the rest of the team and how and to what extent you overcame them. Common problems are:  
 +  * difficulties involving existing software, because of, e.g., 
 +  * its complexity, 
 +  * lack of documentation; 
 +  * lack of suitable supporting software; 
 +  * complications with specific hardware or software platforms; 
 +  * over-ambitious project aims. 
 + 
 +A seemingly disproportionate amount of project time can be taken up in dealing with such problems. The Implementation section gives you the opportunity to show where that time has gone.  
 + 
 +===== The "Testing" ===== 
 + 
 +In this section you should describe your testing strategy and to what extent your part of the system achieved your goals.  
 + 
 +This should include a discussion of the testing approaches used at a team and individual level, e.g. validation, unit testing, integration and systems testing. This is also the place to describe the reasoning behind the tests to evaluate your results, what tests to execute, what the results show and why to execute these tests.  
 + 
 +You should also describe how you demonstrated that your part of system met or exceeded the functional and non-functional requirements of all relevant stakeholders.  
 + 
 +Include comprehensible summaries of the results of all critical tests that were carried out. Detailed documentation of tests can be included in the appendices. 
 + 
 +===== The "Evaluation" ===== 
 + 
 +This section provides a critical evaluation of the final product and the process used to develop the product. This should include: 
 +  * a critical evaluation of the whole product including coverage of the strengths and limitations of the solution system 
 +  * a critical evaluation of the whole process in the form of a discussion that includes the effectiveness of the tools/techniques and the choices made by the team and the student for each phase/iteration of the whole project 
 +  * an analysis of the dynamics of the team in carrying out the whole project. This should be done in a professional manner. Do not include an evaluation of named individuals in the team but discuss how behaviours, problems and actions experienced in the team promoted or hindered effective teamwork . 
 + 
 +===== The "Reflection" ===== 
 + 
 +One of the principles applied throughout the assessment during your studies is that of the value of reflection. We believe that it is important that we reflect upon our performance in order to identify “transferable learning”, that can be carried over into future activities. For example, a “reflective practitioner” would try to identify the characteristics of the problem that has been addressed, and consider whether assumptions or decisions about the relevant approach to solving that problem had been appropriate, in order to make a better decision in relation to problems that might be encountered in the future.  
 + 
 +===== The "Future Work and Conclusions" ===== 
 + 
 +It is quite likely that by the end of your project you will not have achieved all that you planned at the start; and in any case, your ideas will have grown during the course of the project beyond what you could hope to do within the available time. The Future Work section is for expressing the unrealised ideas for your part of the system.  
 + 
 +The Conclusions section should be a summary what you have achieved regarding the suitability, scope, and originality of your part of the system and its main results. An effective set of conclusions should not introduce new material. Instead it should briefly draw out, summarise, combine and reiterate the main points that have been made in the body of the project report and present opinions based on them.  
 +The Conclusions section marks the end of the project report proper. Be honest and objective in your conclusions.  
 + 
 +====== Supporting Material ====== 
 + 
 +===== Abstract ===== 
 + 
 +This is a summary of the report. It must be less than 300 words long. It should give enough information to allow a potential reader to decide whether or not the report will be of interest to them. It should briefly describe the main ideas of the report, including the aims and conclusions. It should be both self-contained and self-explanatory, and it should not say anything not mentioned in the rest of the report (for this reason it is usually written last).  
 + 
 +===== Acknowledgements ===== 
 + 
 +This optional section should be used to record indebtedness for the use of facilities or help from particular sources. You should mention any organisations or people who have helped you while you have been carrying out the project.  
 + 
 +===== Figures ===== 
 + 
 +A project report that uses figures (i.e. diagrams or other pictorial techniques such as tables) to illustrate ideas will probably be easier to digest than one that does not. We therefore recommend that you use figures wherever appropriate.  
 + 
 +When drawing diagrams try to keep to a standard graphical notation that has been introduced during your studies, or that you have seen published widely, and use it consistently.  
 + 
 +All figures should be labelled and captioned, for example,  
 + 
 +''Figure 3.10: Sub-System Architecture.'' 
 + 
 +The label can then be used to refer to the diagram within the text, e.g.  
 + 
 +''See Figure 3.10.'' 
 + 
 +All diagrams must be explicitly referred to somewhere within the text.  
 + 
 +===== References ===== 
 + 
 +We said that you should relate your work to that of other people. Other work explicitly cited should be listed in the Reference section should be referenced using the Harvard Style. It is important that you give proper credit to all work that is not strictly your own, and that you do not violate copyright restrictions.  
 + 
 +Guidance on the Harvard Style of citing and referencing may be viewed at [[http://www.cardiff.ac.uk/insrv/resources/guides/inf057.pdf]].  
 + 
 +Guidance on plagiarism and how to avoid it is available at [[http://learningcentral.cf.ac.uk/bbcswebdav/institution/INSRV/Study%20Skills/plagiarism2/new/index.html]]. 
 +  
 +Note that it is seldom sufficient to simply “cut and paste” material from other sources. When you take material from someone else's work, you are doing so because it helps support your argument, or justify decisions you are making. It is therefore essential to make it clear why you have included material from other sources; in other words, you need to critically assess the work of others, whether it is supporting your position or not. 
 + 
 +===== Appendices ===== 
 + 
 +Appendices are where you present material which you want to include in the report, but which would seriously obstruct the flow of ideas if put anywhere in the main body. This should include a complete set of the deliverables that you developed for your part of the project including any models, test cases and source code 
  
-If you are implementing a piece of software or you intend to design and analyse algorithms the "Implementation" section is quite suitable. If you intend to compare algorithms it may on "Implementation of Algorithms".+Appendices should be headed by letters in alphabetical order, i.e. Appendix A, Appendix B, etc. 
  
-Then present the results of your work and evaluate these results with suitable evidence, discussing the advantages and weaknesses of your approach. You may also consider a section describing the design and results of experiments here, in particular if your project involves evaluating algorithms or similar. The "Conclusions" section should conclude your project overall and your report should end with a reflection on learning.+====== General Advice ======
  
-Do not take any of these section headings as fixed, but instead consider them as a guide. You should adjust the structure of the final report to your specific project and choose suitable sections to represent this. Please discuss the structure and contents of your report with your supervisor.+===== Sections and Subsections =====
  
-===== Individual Report Assessment =====+The main body of the project report should be divided up into sections, along the lines suggested in Structure and Contents or otherwise, as appropriate. Each section should, if necessary, be divided up into subsections, and so on recursively. This can become obscure though if the nesting gets to more than about three levels deep. 
  
-After the submission deadline your supervisor and moderator assess the individual report independently of each other. In addition a [[project viva]] will be held to demonstrate and discuss your project after the complete project has been submitted. The format of the viva varies depending on the project, but generally consists of a demonstration or presentation of the deliverables followed by a discussion of various questions from the supervisor and moderator relating to the project.+It is important that you start each section and subsection with a summary of the rest of the material in it, i.e. inform the reader of what you are about to tell them. This has the effect of “softening up” the reader so that when they move on to the body of the section they feel confident about the direction in which you are taking them. They are reassured at regular intervals when they encounter ideas that you have told them to expect. Without the overview the overall effect is like a mystery tour of ideas, with each new idea coming as a surprise. It is sometimes difficult to appreciate the need for this when you are the author because you are already intimately familiar with the whole route that the report takes.  
 +Each major section should begin on a new page. All sections and subsections should be numbered and headed. Numbering should be like this: 3.10.7 – for subsubsection 7 in subsection 10, in section 3. 
  
-A mark out of 75 is given on the final report, representing 75% of the total mark. The marks awarded for the team report and presentation will be added to the marks given for the individual report to give a total mark from each assessor. If their total marks differ by less than 10, the final mark for the project will be the average between the supervisor's and moderator's total mark. If the difference is 10 or greater, they meet together to discuss the reasons for the difference, and try to come to an agreement. If they cannot agree, a third marker will be appointed. You will receive the total marks with your other module results.+===== Stylistic Conventions =====
  
-The criteria for assessing the individual report are listed below. Please read these carefully as it will help you to see what your assessors will be looking for in your report. Also take into account what you promised to produce for the individual report in your team report, and your supervisor's and moderator's comments on this on PATS. How far you managed to produce these deliverables is part of the individual report assessment.+There are all kinds of stylistic conventions relating to technical writing that you should try to follow. For example: 
 +  * do not use shortened forms such as “don't” for “do not”; 
 +  * avoid colloquialisms and slang words; 
 +  * use British English and write in complete sentences; 
 +  * divide your writing up into paragraphs;
  
-You can resubmit your individual report at any time until the deadline and your supervisor and moderator will not be able to mark this or make any comments online before the deadline. Please discuss your individual report with your supervisor at your regular meetings. You can upload parts of the report onto PATS so that your supervisor can look at these (or give the report in any other way to your supervisor). Just upload the files in the file upload section and your supervisor can see these there (you can, but do not have to submit them until you have the final version).+Writing where the language style or typography, e.g. font or character size, change arbitrarily looks amateurish and can be very distracting for the reader. Use typography to support the content. Other places where consistency should be maintained include:  
 +  * bullet points, 
 +  * use of hyphens, 
 +  * use of capitalisation, 
 +  * technical terms, 
 +  * abbreviations, 
 +  * use of symbols.
  
-===== Assessment Criteria =====+To some extent you can use your own judgement about what conventions to follow. Whatever you do though, you must be consistent. 
  
-Your supervisor and moderator will assess your final report according to the following criteria: +Individual report coursework instructions: {{:cm3301-individualreport.odt|ODT}}, {{:cm3301-individualreport.odt|PDF}}
-  * Problem and background +
-    * Understanding of the problem and the aims and objectives of the project +
-    * Awareness of background to the problem +
-    * Detailed analysis of the problem, suitability of approach towards solving the problem +
-  * Solution to the problem +
-    * Approach and design, integration with the software developed by the team +
-    * Solution, implementation +
-    * Use of and justification for appropriate tools/methods +
-  * Evaluation +
-    * Testing and validation +
-    * Critical appraisal of results, including discussion of how the results link with the other parts of the team project +
-    * Achievement of agreed overall deliverables given in initial plan for the final report (or a justified modification of these) +
-  * Communication and project management skills +
-    * Written (individual report) and oral (viva) communication skills +
-    * Project planning, control and reflection +
-    * Interaction and work with supervisor and the project team +
-    * Review meetings, as specified in the initial plan +
-The scale for this assessment is: +
-  * Third class (>= 40%): The student has clearly defined the problem and made progress towards a solution... +
-  * 2.2 (>= 50%): ...and demonstrated a disciplined approach and adequate solution... +
-  * 2.1 (>= 60%): ...and an appreciation of best practice with a full justification for the solution... +
-  * First class (>=70%): ...and evidence of originality and professionalism and/or scholarship.+

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International