This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
arranging_material_and_structuring_the_project_report [2011/11/14 14:01] – scmfcl | arranging_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 " | 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 " | ||
- | 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 |
- | + | ||
- | 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 | + | |
- | 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 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: | ||
</ | </ | ||
- | ===== The " | + | ===== The " |
- | The purpose | + | This is one suggestion for the description |
+ | |||
+ | ==== Specification and Design | ||
+ | |||
+ | The purpose of specification and design | ||
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). | 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). | ||
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 | + | Implementation is similar to the specification |
- | 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 " | + | ===== The "Conclusions and Future Work" ===== |
- | It is quite likely that by the end of your project | + | 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 |
- | ===== The " | + | It is quite likely that by the end of your project |
- | + | ||
- | 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 | + | |
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 " | We believe in the concept of " | ||
- | |||
- | ===== The " | ||
- | |||
- | We said that you should relate your work to that of other people. Other work explicitly cited should be listed in the Reference section and referred to in the text using some kind of key. 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. | ||
- | |||
- | It may be desirable to provide a Bibliography section separately from the reference section. In general, references are those documents/ | ||
- | |||
- | References should be listed in alphabetical order of author' | ||
- | < | ||
- | Chikofsky, EJ, Cross, JH. 1990. Reverse Engineering and Design | ||
- | Recovery: A Taxonomy. IEEE Software, 7(1):13-17. | ||
- | |||
- | Date, CJ. 2000. An Introduction to Database Systems, 7th Edition. | ||
- | Addison-Wesley. | ||
- | </ | ||
- | are acceptable references. | ||
- | |||
- | There are various conventions for quoting references. For example, you can quote the name of the author and the year of publication, | ||
- | < | ||
- | For more information see [Chikofsky et al, 1990]. A more detailed | ||
- | description is given by Date [2000]. | ||
- | </ | ||
- | |||
- | There are several other variations. For example, some authors prefer to use only the first three or four letters of the name, e.g. [Chi1990] or just to number the references sequentially, | ||
- | |||
- | Whatever convention you choose, be consistent. | ||
- | |||
- | Information Services provide a number of leaflets which describe in detail accepted ways of presenting references. For example, guidance on the Harvard Style of citing and referencing may be viewed at | ||
- | http:// | ||
- | |||
- | Whatever style of referencing you adopt, it is critical that you are assiduous in acknowledging the sources you have used; failure to do so may lead to suspicions of unfair practice and an investigation into whether or not your work reflects the standards expected of academic research. Guidance on plagiarism and how to avoid it is available at | ||
- | http:// | ||
- | |||
- | 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: | ||
- | * If the material you are citing from another source supports your position, you must explain why it should be trusted. For example, material from a published journal will, normally, have been peer-reviewed and can therefore be considered to have some validity, according to subject matter experts. Much of what is published on the Internet cannot be regarded in the same way, however. | ||
- | * You will often find that there are conflicting views in the published material; in such cases you must explain which view you favour and why, before relying on the material to support your position. | ||
- | * If other writers have taken a different position to the one you support, you must explain why the reader should accept your ideas rather than those proposed elsewhere. | ||
- | |||
- | In summary, you need to ensure that you have clearly assessed the relevance of referenced material to the development of your position, or your argument, and demonstrated that you are justified in taking this material to be authoritative. | ||