RMP Resource
  
Free Academic Project Download
  Download Project Synopsis
  Download Project Report
  Download Project Source Code
  Download MBA Projects
   
Setup and Configuration
  ODBC Setup
  IIS Setup
  Restore  MS Sql Database
   
Write Project Documentation
  Abstract
  Synopsis
  Project Report
  Test Case
  Test Plan
  Program Specification
  Implementation
   
Draw Technical Diagram
  HLD
  DLD
  Flow Chart
  Use Case
  ER Diagram
  DFD
  Sequence Diagram
  Class Diagram




RMP Resource - Project Report

Writing project report is very important for any type of project. Project report is document where you transfer your own experiences of doing the project, and the knowledge you have gained, from your brain in a coherent, logical and correct form.

Structure of Report

There is no specific rule to write report. The basic structure of report writing contains following components:

  • Title/Abstract:
    Title should reflect what you have done and should bring out any eye-catching factor of work, for good impact. Abstract is a couple of paragraphs – no more – which summarizes the content of the report. It must be comprehensible to someone who has not read the rest of the report. This is how you attract attention to your writing.
    The abstract should contain the essence of the report, based on which the reader decides whether to go ahead with reading the report or not. It should be short, generally within 2-3 paragraphs. It contain the following in varying amount of detail as is appropriate: main motivation, main design point, essential difference from previous work and methodology.

  • Introduction:
    Introduction is a short version of report. The scope of the project, setting the scene for the remainder of the report. Introduction part should contain the following information:
    • background: what is the setting of the problem
    • problem statement: what exactly is the problem you are trying to solve.
    • motivation: why is the problem important to solve.
    • past/related work: is the problem still unsolved?
    • Challenges : why is the problem difficult to solve.
    • approach : how have you solved the problem.
    • assumption : what are the conditions under which your solution is applicable.
    • summary of the result : what are the main result.
    • What is the summary of your contribution, flow of ideas-how is the rest of the report organized.


  • Background:
    If the project have sufficient background, which the general reader must understand before knowing the details of report, then expand this section separately. It is usual to state that "the reader who knows this background can skip this section" while writing background.


  • Technical section:
    This is the main body of report organization, which is the most problem/work specific. You may also have a separate section for statement of design methodology, or experimental methodology. However, following are the main points in this section
    • Outlines/flow: It is appropriate to have a rough outline of the section at the beginning of that section. Make sure that the flow is maintained as the reader goes from one section to another. there should be no abrupt jumps in ideas.

    • Use of figures: The cliche "a picture is worth a thousand words" is appropriate here. Spend time thinking about pictures. Wherever necessary, explain all aspects of a figure (ideally, this should be easy), and do not leave the reader wondering as to what the connection between the figure and the text is.

    • Terminology: Define each term/symbol before you use it, or right after its first use. Stick to a common terminology throughout the report.

  • Results:
    This section must contain- aspects of system or algorithm you are trying to evaluate, why are you trying to evaluate aspects, cases of comparison,performance matrices, what are parameters under study, what is experimental setup and finally why do the result look the way they do? The results are usually presented as tables and graphs. Identify trends in the data. Does the data prove what you want to establish? In what cases are the result explainable, and in what cases unexplainable if any? It may be useful to summarize the main take-away points from all the data in a separate sub-section at the end of the result section.

  • Future work/Conclusion:
    Generally the reader read the title, abstract, introduction and conclusions. So this is also important section. You have to crisply state the main take-away points from your work. This is similar to the abstract. The difference is that you should assume here that the reader of the conclusions has read the rest of the report.
     

  • References and appendices:
    Do not include references which you have not read, no matter how relevant you think they might be. References must be relevant. If you refer to standard material which is covered by a large number of text-books, choose one or two really good once and cite those, rather than a long list of mediocre texts.

A well structured report has its top-level sections well ordered, and it is easy to get this rights; but each section must in itself be well ordered, and that is more difficult. If possible, include figures close to the text which refers to them, rather than all together in an appendix. Circuit diagrams are, again, a possible exception to this rule. It is normal to list tables and figures at the beginning of the report, after the table of contents.

This is recommended that the following strategy for students who want to produce a high-quality report, which would then have a high potential for being turned into a publication:

  • Think through the outline of the report even as you are working on the details of the problem. Such thinking will also lend focus to your work and you will end up optimizing the returns on the time invested.


  • Two months before the actual deadline, you have to have at least a paragraph-level outline of the report, with all details worked out.


  • After one round of critical analysis by yourselves (or by your group), have another student or another group review it, perhaps in exchange for you reviewing their work. Have them check your flow of ideas. While it may be good to get someone working in the same area, for much of the feedback, this may not really be necessary.

  • Now you are probably about 6-7 weeks from the deadline. At this point, have your advisor/instructor give feedback on the paragraph-level outline. Getting this early is important since, based on this, you may have to reorganize your report, rework your theorems, or rerun your experiments/simulations.


  • Have a pre-final version of the report ready 2 weeks before the deadline. Again, go through one round of self/peer-feedback, and then advisor/instructor feedback.


  • With these 3-4 rounds of revision and critical analysis, the quality of your report is bound to improve.

     
 
 
© 2008 - 2012 RM Solution - All rights reserved.