Wednesday 5 February 2014

623. B. Ph TEXT V – 4 Project Report



V – 4    Project  Report

General Guidelines
Purpose of a report: writing to be read
A key thing to keep in mind right through your report writing process is that a report is written to be read, by someone else.

This is the central goal of report-writing. A report which is written for the sake of being written has very little value.

Before you start writing your report, you need to have in mind the intended audience.
In the narrowest of possibilities, your report is meant for reading by yourselves, and by your advisor/instructor, and perhaps by your evaluation committee. This has value, but only short-term. The next broader possibility is that your report is readable by your peers or your juniors down the line. This has greater value since someone else can continue on your work and improve it, or learn from your work. In the best case possibility, your report is of publishable quality. That is, readable and useful for the technical community in general.

Overall approach: top-down
Take a top-down approach to writing the report (also applies to problem solving in general). This can proceed in roughly three stages of continual refinement of details.
  1. First write the section-level outline,
  2. Then the subsection-level outline, and
  3. Then a paragraph-level outline. The paragraph-level outline would more-or-less be like a presentation with bulleted points. It incorporates the flow of ideas.
Once you have the paragraph-level flow of ideas, you can easily convert that into a full report, by writing out the flow of ideas in full sentences.
While doing the paragraph-level outline, think also about (a) figures, (b) tables, and         (c) graphs you will include as part of the report at various stages. You will find that many things can be better explained by using simple figures at appropriate places.
Another thing to nail-down while doing the paragraph-level outline is the terminology you will be using. For instance, names of various protocols/algorithms/steps in your solution. Or names/symbols for mathematical notation.
The overall approach also includes multiple stages of refinement, and taking feedback from others (peers/advisor/instructor). I will talk about these in more detail after talking about the overall report structure.

Structure of a report
The following should roughly be the structure of a report. Note that these are just guidelines, not rules. You have to use your intelligence in working out the details of your specific writing.

Title and abstract: These are the most-read parts of a report. This is how you attract attention to your writing. The title should reflect what you have done and should bring out any eye-catching factor of your work, for good impact.
The abstract should be short, generally within about 2 paragraphs (250 words or so total). 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 can contain the following in varying amounts of detail as is appropriate: main motivation, main design point, essential difference from previous work, methodology, and some eye-catching results if any.

Introduction: Most reports start with an introduction section. This section should answer the following questions (not necessarily in that order, but what is given below is a logical order). After title/abstract introduction and conclusions are the two mainly read parts of a report.

What is the setting of the problem?
This is, in other words, the background. In some cases, this may be implicit, and in some cases, merged with the motivation below.

What exactly is the problem you are trying to solve?
This is the problem statement.

Why is the problem important to solve?
This is the motivation. In some cases, it may be implicit in the background, or the problem statement itself.

Is the problem still unsolved?
The constitutes the statement of past/related work crisply.

Why is the problem difficult to solve?
This is the statement of challenges. In some cases, it may be implicit in the problem statement. In others, you may have to say explicitly as to why the problem is worthy of a BTech/MTech/PhD, or a semester project, as the case may be.

How have you solved the problem?
Here you state the essence of your approach. This is of course expanded upon later, but it must be stated explicitly here.

What are the conditions under which your solution is applicable?
This is a statement of assumptions.

What are the main results?
You have to present the main summary of the results here.

What is the summary of your contributions?
This in some cases may be implicit in the rest of the introduction. Sometimes it helps to state contributions explicitly.

How is the rest of the report organized?
Here you include a paragraph on the flow of ideas in the rest of the report. For any report beyond 4-5 pages, this is a must.
The introduction is nothing but a shorter version of the rest of the report, and in many cases the rest of the report can also have the same flow. Think of the rest of the report as an expansion of some of the points in the introduction.
Which of the above bullets are expanded into separate sections (perhaps even multiple sections) depends very much on the problem.

Background: This is expanded upon into a separate section if there is sufficient background which the general reader must understand before knowing the details of your work. It is usual to state that "the reader who knows this background can skip this section" while writing this section.

Past/related work: It is common to have this as a separate section, explaining why what you have done is something novel. Here, you must try to think of dimensions of comparison of your work with other work. For instance, you may compare in terms of functionality, in terms of performance, and/or in terms of approach. Even within these, you may have multiple lines of comparison -- functionality-1, functionality-2, metric-1, metric-2, etc.


Technical sections: The main body of the report may be divided into multiple sections as the case may be. You may have different sections which delve into different aspects of the problem. The organization of the report here is problem specific. You may also have a separate section for statement of design methodology, or experimental methodology, or proving some lemmas in a theoretical paper.

The technical section is the most work-specific, and hence is the least described here. However, it makes sense to mention the following main points:

Outlines/flow: For sections which may be huge, with many subsections, 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 is part of the set of technical sections, and is usually a separate section for experimental/design papers. You have to answer the following questions in this section:

Future work: This section in some cases is combined along with the "conclusions" section. Here you state aspects of the problem you have not considered and possibilities for further extensions.

Conclusions: Readers usually read the title, abstract, introduction, and conclusions. In that sense, this section is quite important. You have to crisply state the main take-away points from your work. How has the reader become smarter, or how has the world become a better place because of your work?

No comments:

Post a Comment

647. PRESENTATION SKILLS MBA I - II

PRESENTATION  SKILLS MBA   I - II There are many types of presentations.                    1.       written,        story, manual...