help needed for the format of the project report
nehasharmabms
Par 100 posts (V.I.P)
see all that will b told to u by ur college faculty they will tell u the entire format cause u will better understand when u c the hard copy
bonddonraj
Par 100 posts (V.I.P)
The advice below consists of a set of suggestions of material that you might include in your report. A particular report should only include those parts that are relevant. This is not intended to give advice as to the ordering or names of the sections of your project. Talk to your supervisor about precisely how to break up your work into appropriate sections.
1. Write about the interesting parts of your project
No-one wants to read about every detail of how you implemented your project.
First and foremost, you should write about the most interesting or important parts of your project. Devote most space and time to this. For example:
What design choices did you have along the way, and why did you make the choices you made?
What was the most difficult part of the project? Why was it difficult? How did you overcome the difficulties?
Did you discover anything novel?
What did you learn?
2. Write about the context in which your work fits.
You should provide enough background to the reader for them to understand what the project is all about. For example:
What problem are you solving?
Why are you solving it?
How does this relate to other work in this area?
What work does it build on?
Your reader is technically literate, but may not understand in detail the area of your project or any tools or building blocks you've used, so help them understand.
3. Give an overview of your work
If your project involved designing a system, give a good high-level overview of your design.
In many projects, the initial design and the final design differ somewhat. If the differences are interesting, write about them, and why the changes were made.
If your design is was not implemented fully, describe which parts you did implement, and which you didn't. If the reason you didn't implement everything is interesting (eg it turned out to be difficult for unexpected reasons), write about it.
4. Describe any preparatory work you needed to do.
Some projects involve detailed requirements capture, and some the requirements are essentially handed to you.
If you had to do detailed requirements capture (eg a survey of potential users, etc), then this might be described in some detail.
If you didn't do detailed requirements capture, then just summarise the requirements.
5. Provide a User Manual
For all software projects, you need to include enough information to show how to run the software (see "Appendices" below). But some projects are heavily user-centered, and so the user interface is a key part of the project; in these cases a user manual would not just be an appendix, but a core part of the project report. However, structuring it as a user manual may not be the most effective way to present your ideas, so use your discretion.
5. Describe how you evaluated your work
Most projects involve building software systems. Building software that works well is difficult, and you may have spent a lot of time on testing. In most cases your reader does not want to know about all the detailed tests you ran, but they will be interested in your testing strategy and philosophy. Some software is particularly hard to test, and in such cases you might need to go into quite some detail on why it's hard to test, and how you overcame this obstacle.
Some projects involve designing systems whose final correct behaviour is not known in advance - usually such projects would be classed as "research" projects. Typically such a project report will devote a lot of time to evaluation of how the final system behaved, and where it worked well and where it didn't. No system behaves well in all circumstances, so your reader will be interested in both how well it works, and in the circumstances in which it works less well.
6. Provide a critical evaluation of your work
Your reader wants to know that you understand the advantages, disadvantages, strengths and limitations of your work. No project is perfect - there's never enough time for that. Provide a critique of your work. Some examples:
Did the design did the job you intended, or were there problems?
How does the resulting system compare against the competition?
If you didn't finish implementing all the features, how hard do you think it would be to do so?
What advice would you have for someone who wished to take your system and use it or extend it?
What would you do differently if you could start all over again?
Addendices of the Report
You MUST add the following appendices if they are relevant to your project. The appendices are not themselves marked, but they provide important background information to your examiner.
System Manual
This should include all the technical details (where is the code? what do you type to compile it? etc) that would enable a student to continue your project next year, to be able to amend your code and extend it.
User manual
(Include as an appendix if not already covered in the main report).
This should give enough information for someone to use what you have designed and implemented.
Test results
If you have test results that add to the value of the report, but which would not fit within the page limit of the main report, you can include then as an appendix. Don't add them just to pad the report though.
Project Plan and Interim Report
If you handed in these documents (which will be the case for the vast majority of you), please also put copies of them in the Appendix of your report. However you should note that you are being asked to do this in order to comply with a request from the external examiners, and that these documents will not be part of the formal internal assessment of your project by the 1st/2nd markers.
Code Listing
Your code should be well commented. In order not to use up too many pages of your maximum 120 on code, you may like to use the 'a2ps' Unix facility, which allows you to put two pages of code onto one side of paper - see the Unix 'man' pages for details.
Don't add more than about 25 pages of code listing to the report.
If your code does not fit within 25 pages, you can provide a listing of the most interesting parts our your code (but include around 20-25 pages). If you don't include everything, it must be clear that this is not the complete listing. Make it clear which parts you've include, add a brief explanation of why you've included these particular parts, and provide a brief summary of which code you have omitted.
You must make the rest available on a CD-ROM. You will need to bring in two copies of any CDs you include when you hand in your project report, one to go with each copy of your project.
Bibliography
Give publication details for all the references you have made in the report.
The format requirements are not overly restrictive - for example there is no requirement for you to use a particular font style. However, do not use too many different typefaces in your report, or in general spend too much time developing an elaborate visual presentation. It is better to keep the look of your project report simple and straightforward. (An elaborate presentation can in fact create a negative impression, that the author thought that the material was rather thin and felt that an eye-catching style might disguise this!)
By all means use plotting/drawing packages to create graphs and figures, but if, for example, it is going to take you most of a week to learn to use a drawing package, you would be better advised to hand-draw your figures neatly and get on with something else. You would lose few, if any, marks for having hand-drawn a picture, and your time is precious.
Title
As well as the title of the project, the year of submission, and your own name, the cover sheet on your project should also include the name(s) of your supervisor(s) and your degree programme (BSc, MSci, etc). Use the format of this sample cover sheet.
Disclaimer
On the title page you must include a disclaimer in the words given below.
This report is submitted as part requirement for the [BSc, MSci or MSc] Degree in [your degree title, 'Computer Science', 'Computer Science with...', 'Information Technology', etc] at University College London. It is substantially the result of my own work except where explicitly indicated in the text.
Then follow this with the words
The report may be freely copied and distributed provided the source is explicitly acknowledged.
or, if you project includes confidential information that prevents it being more widely circulated, by
The report will be distributed to the internal and external examiners, but thereafter may not be copied or distributed except with permission from the author.
Most people should be using the first version.
--------------------------------------------------------------------------------
Students are reminded that the project is an individual project and that the work submitted should be substantially your own as stated in the standard disclaimer (above) that you are required to put on your project submission.
You should identify clearly in your report:
which work you have completed by yourself and represents your own individual contribution
which work you have completed in conjunction with other students with whom you have collaborated (such as fellow students from your degree programme)
which work you have incorporated from other sources, such as from previous years' students, from external sources (e.g. third party algorithms, methods, publications, source code or code libraries), or from Research Projects with which you have been allied with during your project work (e.g. those of your Supervisor or of external companies)
--------------------------------------------------------------------------------
Abstract
On the page immediately following the title page you must have a short abstract (no more than one page in length) giving a descriptive summary of your project. You will also need to submit three unbound copies of an abstract when the time comes to hand in; you can use the same text here as for the abstract that is within your report, but please put your name, your supervisor's name and the project title on these unbound abstract copies.
--------------------------------------------------------------------------------
Other format requirements
The main body of your report (excluding appendices and code listing) should normally not be more than about 40 pages, and should include information about the most interesting aspects of your project. If you write a lot more than this, it may be regarded as padding, and will not be viewed favourably by your examiners. However there is no hard bound on the length of your project - if you really have a large amount of interesting information to include, then please do so. Each project is unique and has its own natural length, and you will probably know when you have said everything that you think needs to be said. If in doubt, of course, ask your supervisor if they think you've included everything that's relevant.
You are strongly recommended to use 12 point type and 1.5 or double spacing. On no account should you use a typeface less than 10 points - it's unreadable! It is also preferable to use single-sided printing, as the result when bound by the departmental machine is more easily readable.
Pages should be numbered (in case they become accidentally separated before the report has been bound).
It must be possible for the whole work to be bound in a single volume.
1. Write about the interesting parts of your project
No-one wants to read about every detail of how you implemented your project.
First and foremost, you should write about the most interesting or important parts of your project. Devote most space and time to this. For example:
What design choices did you have along the way, and why did you make the choices you made?
What was the most difficult part of the project? Why was it difficult? How did you overcome the difficulties?
Did you discover anything novel?
What did you learn?
2. Write about the context in which your work fits.
You should provide enough background to the reader for them to understand what the project is all about. For example:
What problem are you solving?
Why are you solving it?
How does this relate to other work in this area?
What work does it build on?
Your reader is technically literate, but may not understand in detail the area of your project or any tools or building blocks you've used, so help them understand.
3. Give an overview of your work
If your project involved designing a system, give a good high-level overview of your design.
In many projects, the initial design and the final design differ somewhat. If the differences are interesting, write about them, and why the changes were made.
If your design is was not implemented fully, describe which parts you did implement, and which you didn't. If the reason you didn't implement everything is interesting (eg it turned out to be difficult for unexpected reasons), write about it.
4. Describe any preparatory work you needed to do.
Some projects involve detailed requirements capture, and some the requirements are essentially handed to you.
If you had to do detailed requirements capture (eg a survey of potential users, etc), then this might be described in some detail.
If you didn't do detailed requirements capture, then just summarise the requirements.
5. Provide a User Manual
For all software projects, you need to include enough information to show how to run the software (see "Appendices" below). But some projects are heavily user-centered, and so the user interface is a key part of the project; in these cases a user manual would not just be an appendix, but a core part of the project report. However, structuring it as a user manual may not be the most effective way to present your ideas, so use your discretion.
5. Describe how you evaluated your work
Most projects involve building software systems. Building software that works well is difficult, and you may have spent a lot of time on testing. In most cases your reader does not want to know about all the detailed tests you ran, but they will be interested in your testing strategy and philosophy. Some software is particularly hard to test, and in such cases you might need to go into quite some detail on why it's hard to test, and how you overcame this obstacle.
Some projects involve designing systems whose final correct behaviour is not known in advance - usually such projects would be classed as "research" projects. Typically such a project report will devote a lot of time to evaluation of how the final system behaved, and where it worked well and where it didn't. No system behaves well in all circumstances, so your reader will be interested in both how well it works, and in the circumstances in which it works less well.
6. Provide a critical evaluation of your work
Your reader wants to know that you understand the advantages, disadvantages, strengths and limitations of your work. No project is perfect - there's never enough time for that. Provide a critique of your work. Some examples:
Did the design did the job you intended, or were there problems?
How does the resulting system compare against the competition?
If you didn't finish implementing all the features, how hard do you think it would be to do so?
What advice would you have for someone who wished to take your system and use it or extend it?
What would you do differently if you could start all over again?
Addendices of the Report
You MUST add the following appendices if they are relevant to your project. The appendices are not themselves marked, but they provide important background information to your examiner.
System Manual
This should include all the technical details (where is the code? what do you type to compile it? etc) that would enable a student to continue your project next year, to be able to amend your code and extend it.
User manual
(Include as an appendix if not already covered in the main report).
This should give enough information for someone to use what you have designed and implemented.
Test results
If you have test results that add to the value of the report, but which would not fit within the page limit of the main report, you can include then as an appendix. Don't add them just to pad the report though.
Project Plan and Interim Report
If you handed in these documents (which will be the case for the vast majority of you), please also put copies of them in the Appendix of your report. However you should note that you are being asked to do this in order to comply with a request from the external examiners, and that these documents will not be part of the formal internal assessment of your project by the 1st/2nd markers.
Code Listing
Your code should be well commented. In order not to use up too many pages of your maximum 120 on code, you may like to use the 'a2ps' Unix facility, which allows you to put two pages of code onto one side of paper - see the Unix 'man' pages for details.
Don't add more than about 25 pages of code listing to the report.
If your code does not fit within 25 pages, you can provide a listing of the most interesting parts our your code (but include around 20-25 pages). If you don't include everything, it must be clear that this is not the complete listing. Make it clear which parts you've include, add a brief explanation of why you've included these particular parts, and provide a brief summary of which code you have omitted.
You must make the rest available on a CD-ROM. You will need to bring in two copies of any CDs you include when you hand in your project report, one to go with each copy of your project.
Bibliography
Give publication details for all the references you have made in the report.
The format requirements are not overly restrictive - for example there is no requirement for you to use a particular font style. However, do not use too many different typefaces in your report, or in general spend too much time developing an elaborate visual presentation. It is better to keep the look of your project report simple and straightforward. (An elaborate presentation can in fact create a negative impression, that the author thought that the material was rather thin and felt that an eye-catching style might disguise this!)
By all means use plotting/drawing packages to create graphs and figures, but if, for example, it is going to take you most of a week to learn to use a drawing package, you would be better advised to hand-draw your figures neatly and get on with something else. You would lose few, if any, marks for having hand-drawn a picture, and your time is precious.
Title
As well as the title of the project, the year of submission, and your own name, the cover sheet on your project should also include the name(s) of your supervisor(s) and your degree programme (BSc, MSci, etc). Use the format of this sample cover sheet.
Disclaimer
On the title page you must include a disclaimer in the words given below.
This report is submitted as part requirement for the [BSc, MSci or MSc] Degree in [your degree title, 'Computer Science', 'Computer Science with...', 'Information Technology', etc] at University College London. It is substantially the result of my own work except where explicitly indicated in the text.
Then follow this with the words
The report may be freely copied and distributed provided the source is explicitly acknowledged.
or, if you project includes confidential information that prevents it being more widely circulated, by
The report will be distributed to the internal and external examiners, but thereafter may not be copied or distributed except with permission from the author.
Most people should be using the first version.
--------------------------------------------------------------------------------
Students are reminded that the project is an individual project and that the work submitted should be substantially your own as stated in the standard disclaimer (above) that you are required to put on your project submission.
You should identify clearly in your report:
which work you have completed by yourself and represents your own individual contribution
which work you have completed in conjunction with other students with whom you have collaborated (such as fellow students from your degree programme)
which work you have incorporated from other sources, such as from previous years' students, from external sources (e.g. third party algorithms, methods, publications, source code or code libraries), or from Research Projects with which you have been allied with during your project work (e.g. those of your Supervisor or of external companies)
--------------------------------------------------------------------------------
Abstract
On the page immediately following the title page you must have a short abstract (no more than one page in length) giving a descriptive summary of your project. You will also need to submit three unbound copies of an abstract when the time comes to hand in; you can use the same text here as for the abstract that is within your report, but please put your name, your supervisor's name and the project title on these unbound abstract copies.
--------------------------------------------------------------------------------
Other format requirements
The main body of your report (excluding appendices and code listing) should normally not be more than about 40 pages, and should include information about the most interesting aspects of your project. If you write a lot more than this, it may be regarded as padding, and will not be viewed favourably by your examiners. However there is no hard bound on the length of your project - if you really have a large amount of interesting information to include, then please do so. Each project is unique and has its own natural length, and you will probably know when you have said everything that you think needs to be said. If in doubt, of course, ask your supervisor if they think you've included everything that's relevant.
You are strongly recommended to use 12 point type and 1.5 or double spacing. On no account should you use a typeface less than 10 points - it's unreadable! It is also preferable to use single-sided printing, as the result when bound by the departmental machine is more easily readable.
Pages should be numbered (in case they become accidentally separated before the report has been bound).
It must be possible for the whole work to be bound in a single volume.
sandhya2705
New member
Hi ,
hey i m also looking for a format of a project. if u have it, cud u plz send it to me or post it.
hey i m also looking for a format of a project. if u have it, cud u plz send it to me or post it.
sandhya2705
New member
hey thanks a lot.
it was really informative.
thanks.
bye
Sandhya.
it was really informative.
thanks.
bye
Sandhya.