Site Tools

Trace:
arranging_material_and_structuring_the_project_report

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
arranging_material_and_structuring_the_project_report [2022/10/08 14:39] – scmfclarranging_material_and_structuring_the_project_report [2023/03/16 12:54] (current) – scmfcl
Line 3: Line 3:
 You should consider, at the beginning of your project, what you need to do to solve the problem you have chosen to address. This will then inform choices about the structure of your reports; your written reports need to be both a "narrative" (telling the story of your project) and an "argument" (providing a logical justification of the steps you have undertaken to solve your chosen problem). Once you have started to gather material you can begin to arrange it in a form which can then be refined into a report, though the outline chapter headings shown below will serve as a good guide in the early stages of your work. You should consider, at the beginning of your project, what you need to do to solve the problem you have chosen to address. This will then inform choices about the structure of your reports; your written reports need to be both a "narrative" (telling the story of your project) and an "argument" (providing a logical justification of the steps you have undertaken to solve your chosen problem). Once you have started to gather material you can begin to arrange it in a form which can then be refined into a report, though the outline chapter headings shown below will serve as a good guide in the early stages of your work.
  
-All good project reports whatever their subject, follow certain well-established conventions and have a similar overall shape. They generally consist of a main body surrounded by other information (presented in appropriate formats) that support it in various ways. Some of these are mandatory, others are optional. +All good project reports whatever their subject, follow certain well-established conventions and have a similar overall shape. They generally consist of a main body surrounded by other information (presented in appropriate formats) that support it in various ways. Some of these are mandatory, others are optional. You can vary the titles of the sections if these are inappropriate for your project - your supervisor is the best person to guide you on this. Here we concentrate on the main body of the report and generic sections. We recommend for writing the report that you start with an outline of the main and sub-sections (or chapters and sections) as a guide on what you should be writing in detail.
- +
-Suggestions of the particular structure for the final and interim reports are given in the +
-[[Interim Report]] and [[Final Report]] topics on this wiki. You should vary the titles  +
-of the sections if these are inappropriate for your project - your supervisor is the best person to guide you on this. Here we concentrate on the main body of the report and generic sections for both reports. The supporting information is discussed later. We recommend that you do the same when writing your report, though you should have a plan for your report which will guide you on what material your should be retaining for eventual inclusion.+
  
 We look at each of the general sections of the report structure 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. We look at each of the general sections of the report structure 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.
Line 88: Line 84:
 </code> </code>
  
-===== The "Specification & Design" =====+===== The "Specification, Design and Implementation" =====
  
-The purpose of the Specification and Design sections is to give the reader a clear picture of the system you plan to create, in terms of the capability required. A specification should tell the reader what the software system is required to do. The design then gives the top-level details of how the software system meets the requirement. It will also identify constraints on the software solution, that are important in guiding decision making throughout the development process.+This is one suggestion for the description of how your solution works. In some cases a methodology or approach to solve the problem may be more suitable to present the work. For this part, in particular, you have a lot of freedom of how to structure your report to present your solution. 
 + 
 +==== Specification and Design ==== 
 + 
 +The purpose of specification and design is to give the reader a clear picture of the system you plan to create, in terms of the capability required. A specification should tell the reader what the software system is required to do. The design then gives the top-level details of how the software system meets the requirement. It will also identify constraints on the software solution, that are important in guiding decision making throughout the development process.
    
 Describing what a software system does (specification) and how it does so (design) effectively usually means describing it from more than one viewpoint. Each viewpoint will convey some information about the system that other viewpoints omit. (You would use the same technique when describing any complicated construction such as a building, an aircraft, a novel or a painting).  Possible viewpoints might be: Describing what a software system does (specification) and how it does so (design) effectively usually means describing it from more than one viewpoint. Each viewpoint will convey some information about the system that other viewpoints omit. (You would use the same technique when describing any complicated construction such as a building, an aircraft, a novel or a painting).  Possible viewpoints might be:
Line 111: Line 111:
 If you are not designing a system, but testing a hypothesis for a more scientifically oriented project, specification and design sections may not be required in quite the same form. The specification instead becomes a description of the problem and what is required of a solution. The design becomes a description of your approach to solving the problem and your suggested solution(s). For instance, if you are designing an algorithm to solve a particular problem you would have a problem statement section and then a section describing one or more suggested algorithms to solve the problem. Later in the Results and Evaluation section you then describe how to design experiments to test how well the algorithm(s) solve the problem and present your experimental results with an evaluation of your suggested solutions. If you are not designing a system, but testing a hypothesis for a more scientifically oriented project, specification and design sections may not be required in quite the same form. The specification instead becomes a description of the problem and what is required of a solution. The design becomes a description of your approach to solving the problem and your suggested solution(s). For instance, if you are designing an algorithm to solve a particular problem you would have a problem statement section and then a section describing one or more suggested algorithms to solve the problem. Later in the Results and Evaluation section you then describe how to design experiments to test how well the algorithm(s) solve the problem and present your experimental results with an evaluation of your suggested solutions.
  
-===== The "Implementation" =====+==== Implementation ====
  
-The Implementation section is similar to the Specification and Design section in that it describes the system, but it does so at a finer level of detail, down to the code level. This section is about the realisation of the concepts and ideas developed earlier. It can also describe any problems that may have arisen during implementation and how you dealt with them.+Implementation is similar to the specification and design in that it describes the system, but it does so at a finer level of detail, down to the code level. This section is about the realisation of the concepts and ideas developed earlier. It can also describe any problems that may have arisen during implementation and how you dealt with them.
  
-Do //not// attempt to describe all the code in the system, and do //not// include large pieces of code in this section. Complete source code should be provided separately. Instead pick out and describe just the pieces of code which, for example:+Do //not// attempt to describe all the code in the system, and do //not// include large pieces of code in this section. Complete source code should be provided separately. Instead, pick out and describe just the pieces of code which, for example:
   * are especially critical to the operation of the system;   * are especially critical to the operation of the system;
   * you feel might be of particular interest to the reader for some reason;   * you feel might be of particular interest to the reader for some reason;
Line 142: Line 142:
 This section also gives you an opportunity to present a critical appraisal of the project as a whole. This could include, for example, whether the methodology you have chosen and the programming language used were appropriate. This section also gives you an opportunity to present a critical appraisal of the project as a whole. This could include, for example, whether the methodology you have chosen and the programming language used were appropriate.
  
-===== The "Future Work" =====+===== The "Conclusions and Future Work" =====
  
-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 your unrealised ideas. It is a way of recording that 'I have thought about this', and it is also a way of stating what you would like to have done if only you had not run out of time (Remember to take into account Hofstadter’s Law: 'Everything takes longer than you think, even when you take into account Hofstadter's Law.'). A good Future Work section should provide a starting point for someone else to continue the work which you have begun.+The Conclusions section should be a summary of the aims of project and a restatement of its main results, i.e. what has been learnt and what it has achieved. 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" ===== +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. You can include discussion of future work in the conclusions or as a discussion at the end of the evaluation section. It is for expressing your unrealised ideas, focused in particular of what you suggest as next steps (possibly emerging out of your evaluation). It is a way of recording that 'I have thought about this', and it is also a way of stating what you would like to have done if only you had not run out of time (Remember to take into account Hofstadter’s Law: 'Everything takes longer than you think, even when you take into account Hofstadter's Law.'). Ideally it should provide a starting point for someone else to continue your work.
- +
-The Conclusions section should be a summary of the aims of project and a restatement of its main results, i.e. what has been learnt and what it has achieved. 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. The Conclusions section marks the end of the project report proper. Be honest and objective in your conclusions.
Line 155: Line 153:
  
 We believe in the concept of "lifelong learning". 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. Reflection should focus on what Argyris calls "double loop learning"; this is where we identify, not relatively "simple skills", such as the mastery of a new programming language, but the impact of what we have done on the assumptions, concepts and ideas we used to make decisions about our work. 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. We believe in the concept of "lifelong learning". 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. Reflection should focus on what Argyris calls "double loop learning"; this is where we identify, not relatively "simple skills", such as the mastery of a new programming language, but the impact of what we have done on the assumptions, concepts and ideas we used to make decisions about our work. 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.
- 
  
arranging_material_and_structuring_the_project_report.txt · Last modified: 2023/03/16 12:54 by scmfcl

Page Tools

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