Electronic assignment help
talkinghead
group_project_report_structure_guide.docxSUGGESTED STRUCTURE FOR GROUP PROJECT REPORT
The following information is a revised subset of the Major Project Handbook given to Year 3 BEng students, however, its revision means that it may also be used, in revised form, for the Group Project report.
The following is meant to be a guide to help you, not a straight-jacket. Each major section should be present in some way, although not necessarily in a chapter of its own. The chapter layout must be appropriate to each particular project.
Referencing:
A significant guide to referencing is included in appendices 4 and 5. Note that your External Examiner is keen to ensure we, as staff, take particular note of the quality and accuracy of your referencing; so you should too.
.
1. TITLE
· Title of work
· Full name of student
· Name of Supervisor
· Date of submission
Example:
|
A Study of the use of Wireless Underwater Sensor Networks in Swansea Bay
by Joe Bloggs
Supervisor: Dr Kapilan Radhakrishnan
April 2014 |
2. DECLARATION FORM (see Appendix 1)
This states that the candidate is the author of the Project and the work contained therein has been done by the candidate.
3. ABSTRACT (1 page or around 300 words)
The abstract is short summary of the entire project. It should summarise the important points and should include:
a) The overall aims and objectives.
b) A summary of the methods used.
c) A summary of the major findings and/or deliverables.
d) A statement of conclusions and recommendations.
Keep it concise. The idea of the Abstract is that someone could read it and decide from it whether it would be worth their while to read the whole report. Although it’s the first thing that appears in the report, it is the last thing to be written.
4. CONTENTS PAGE
Show the main chapter and the sub-chapters. Also provide a List of Tables/Figures.
CHAPTER 1 - INTRODUCTION
This chapter should start off by setting the context for the work:
· What is the project about? What are the initial aims and objectives for the project?
· Aim - what is the overall research question you're trying to answer?
· Objectives - what are the actions you're going to take to try to satisfy the aim?
· A brief description of what is coming up in the following chapters (this should be the final paragraph of the introduction).
Usually, you start with a very broad statement of the problem and refine that down to more specific items. Unless yours is a problem area with which all readers of your report will be familiar (very unlikely), you will want to describe the problem in some detail and give sufficient background information so that everyone can understand it.
You should then describe the objectives, aims or goals of your particular piece of work. Your overall aim was presumably to solve a particular problem or to answer a particular question. This could be broken down into a number of specific objectives that together work towards achieving the aim.
The introduction should end with a section that leads the reader in to the rest of the report. The important thing is to give your reader a clear picture of what your report is setting out to do.
CHAPTER 2 - RESEARCH & REVIEW OF LITERATURE
Year 2 projects should include some element of review and scholarly research. Your work is done in the context of an academic discipline; Electronics. Show how your project fits into the framework of that discipline by reviewing books and papers describing the problem you are trying to solve and potential solutions to the problem.
The listing below is probably too detailed for a Group Project, however, it gives you enough detail to help you to consider what you might include.
· What other research has been done in your field?
· Who did this research?
· What were their results?
· How do these results relate to other researchers' work in the field?
· Split the literature review into sections, each looking at a different part of the research problem
· Write an introductory paragraph at the start of the chapter that briefly describes the sections
· Write a concluding paragraph at the end of the chapter that briefly sums up the most important points.
The Literature Review gives your reader sufficient background knowledge for them to be able to appreciate later why the approach you took was valid or best. Since they may not be familiar with either the problem or the possible solutions or both, you need to provide them with a basic grounding in the important and relevant material. This does not, however, mean that you should include a detailed tutorial.
You also need to demonstrate that you considered a number of possible solutions to the problem and that you took a range of material into account. This part of the review usually summarises quite succinctly approaches that have been taken by other people in similar situations. Some will have been successful and some not, and this should be indicated. It is perfectly all right to express justified disagreement with something you’ve read - “criticism” is often an excellent feature of a review.
The most important attribute that your review should possess is relevance.
It is strongly recommended that a first draft of this section is developed in the first term.
CHAPTER 3 - RESEARCH AND/OR DEVELOPMENT METHODOLOGY
This section is overly detailed for Year 2 Group Project, however, it has been left in for you to get a flavour of what’s to come on a degree course, if applicable to you. You should try to address at least some of the ideas presented here.
Research Methodology
Here you explain in detail the what, why and how of the procedures you used in order to generate the solution to the idea.
The rule is to describe your method in sufficient detail to allow the reader to replicate your study. What research methodology/methodologies did you use - experimental (hypothesis testing), investigative, action, survey, case-study etc? Do not include a review of all possible methods that could be used – the reader is interested in what method you chose and why.
For each of the layers of the research onion, decide which method you intend to use and explain:
· Why you have chosen that method
· What are the advantages of that method to your project
· If there are any disadvantages to the method then how will you work around them?
Also indicated what evaluation criteria are to be used? What methods of testing and statistical analysis are to be used?
Development Methodology (for Development-based Projects)
· For your given design and construction project explain:
· Why you have chosen your particular method of implementation
· What are the advantages of that method to your project
· If there are any disadvantages to the method then how you will work around them.
· What software/hardware are you going to use, and why is it appropriate for the project?
· Do you need any particular hardware, and if so why?
· Materials and Tools. eg why are you using a particular package or language to design and develop your software?
CHAPTER 4 - DESIGN & IMPLEMENTATION
This is a major section which describes your deliverable. It may be a hardware or software artefact.This may span more than one chapter and will have title(s) which reflect its content.
Design
If you’ve built something to solve a problem, you had to make some design decisions along the way. Why did you choose to do something one way rather than another? Why did you choose to include one thing but leave out something else? Which factors did you think were most important and which did you choose to ignore?
Don’t just list your decisions; place them in a context. It should be possible for the reader to understand how your design decisions contributed to meeting your objectives. Also important is that you show the method by which you accomplished your design - “process” is as important as “product” to an engineer.
· What processes did you use?
· How did they contribute to ensuring that what you did was complete/consistent/correct?
It should be possible for the reader to understand how your design decisions contributed to meeting your objectives. Also important is that you show the method by which you accomplished your design - “process” is as important as “product” to an engineer. What processes did you use? How did they contribute to ensuring that what you did was complete/consistent/correct? Don’t just write about what you did, or how you did it. Why you did it is most important.
The starting point for your design is, of course, your requirements. In some projects the requirements are specified in advance. The customer provides a document that (in more or less detail) specifies the behaviour of the item to be constructed. More commonly, the customer has a more vague “need” for something, and it is part of the project itself to refine that into a more detailed set of requirements. A project that doesn’t have a written set of requirements is not a very good one, though it would not be normal to describe the requirements in much detail in the body of the report. It is better to include the requirements specification document as an appendix to your report. If a detailed discussion of how you elicited, analysed and specified the requirements is necessary, (for “necessary”, read interesting and relevant), it could be a separate chapter before this one.
The “design” stage is often held to be the key stage of your project. It is certainly the part of project reports that is most closely looked at by external examiners! It is the one where you can show off your ability to apply your engineering and commercial knowledge and skills to best advantage. This is precisely what you will be doing in your working life if your chosen career is in any way related to your degree.
Implementation
After you designed your solution to your problem, you implemented it. This section normally describes how you did that. What tools and techniques did you use? What difficulties did you encounter, and how did you overcome them?
This chapter of your report should only address issues that are interesting. Mundane details about how the program is structured should be left out. On the other hand, if you developed something new or applied an old technique in a new way, then that is of interest and should be included.
If, in your project, you designed something but did not build it, there may still be scope for an equivalent to this chapter, in that you could discuss issues that would probably arise during future implementation and provide advice on how potential problems could best be prevented or solved.
Involving potential users of the system in the evaluation is always a good idea, where applicable. If this can be done in a simulation of the real environment, then so much the better. Feedback from users which is structured is more useful than their verbal comments.
CHAPTER 5 – EVALUATION
Evaluation usually comes in one of two forms: either you compare what you did with your objectives, or you can compare what you did with what someone else did.
· What conclusions can be drawn from your data?
· Did your data back up the research in your literature review or disagree with it?
· Did you meet your objectives? If not, why not?
· Did you meet your aim? If not, why not?
· Overall, are the answers what you would expect? If not then why not?
· If you were to do it again, what would you do differently?
CHAPTER 6 - CONCLUSIONS AND RECOMMENDATIONS
· This section should summarise everything you've done
· Does your project suggest any further avenues for research?
This chapter is where you tie up all the loose ends in the previous chapters. It is most important that it relates to what you have described previously, and that it does so in a relevant and concise fashion.
In your summing-up, you need to show how what you did contributed to meeting the objectives you set in the introduction. In doing so, it is appropriate to repeat (in summary form) key points from your review, design, implementation and evaluation as necessary.
Any further work that can, or should, be undertaken to expand upon your work is to be highlighted, fully explained and justified. The benefits gained from your work should be identified (these are not to include personal benefits). Also, any recommendations should be included here.
It is perfectly OK to have some loose ends left at the end of a project. Sometimes there will be aspects you simply did not have time to address. Other times there will be things that you were unable to do because of force of circumstances. Above all, there will have been pointers raised during the course of the project that you did not anticipate and were not within your scope to tackle. All these things can be discussed in this chapter and, where further work can be identified, a distinct sub-section, “Suggestions for further work”, should be included.
CHAPTER 7 – REFLECTION
The key question here is:
· What did you learn while doing the project? How did it change you as a person?
You will need to reflect upon the work that you’ve done and there is a specific mark allocated to this in the marking scheme. Reflection is the process of looking back at something which has happened in order to show what you have learned from it. The purpose of reflective writing is to help you learn from a particular practical experience. It will help you to make connections between the documented theory and what you did in practice. Through reflection, you should be able to make sense of what you did and help yourself to do a superior job next time. Put simply - could you have done it better and, if so, how?
CHAPTER 8 – REFERENCES
A list of references (work directly quoted or paraphrased in your text) and its source. For more information on this, see Appendices 4 and 5.
CHAPTER 9 – BIBLIOGRAPHY
A list of background reading undertaken, but not necessarily directly quoted in the text.
APPENDICES
Appendices to a report contain information that, while not important or interesting enough to be included in the body of the report, is nevertheless relevant. Common examples include program source code, program documentation, intermediate documents. Your report stands alone without these, but the reader may occasionally wish to refer to them.
The key word here is “occasionally”. If it is crucial to read something in order to understand some point being made in the report, then that “something” should be replicated in the body of the report.
· Test data used to evaluate the product.
· Tables too detailed for the main text
· Technical notes
· Copies of documents not generally available but referred to in the report
(Note: If you have a lot of program source code, do not print it all out, instead provide it on a CD or DVD)
8.2 GENERAL POINTS ABOUT REPORT
8.2.1 Spelling and Grammar
You should take care to present your work in an attractive, legible format.
Spelling and grammar should always be checked as part of the proof reading process. A poor standard of spelling will create a poor impression to the reader and will invariably be marked down as will poor sentence construction and punctuation. Be careful when using the spell checker on the word processing package that it is set to UK English and not US English.
8.2.2 Word Limit
The Project documentation has a word limit of 5,000-10000 words. Other relevant material, eg code listings, may be included in appendices and are not subject to the word limit.
The word limit is set for the following reasons:
a) The discipline to write at this length is considerable. It is a substantial piece of academic work yet it requires good editorial skills to avoid excessive length.
b) It encourages incisiveness and a good grasp of technical/theoretical
issues to bring them into sharp focus.
c) It necessitates a tight definition of the topic.
d) It necessitates a meaningful analysis of the relevant literature not a mere
listing of sources with brief comments.
e) It necessitates communication of complex ideas in clear and precise fashion.
Condensing a lot of information/ ideas into a well-structured answer within the word limit is a real skill. It shows you have the ability to sift information, construct an argument, and express yourself succinctly. If you have difficulty "pruning" material to fit a word limit, remember that economy of words and clarity of expression are important. Sometimes, it may be useful to create footnotes/endnotes or appendices so that you can refer to information without losing the thrust of your argument.
8.2.3 Style Requirements
You should make sure that the final submitted versions of your work conform with the following specifications. If in any doubt, consult your supervisor or the Project Co-ordinator.
· White, A4 paper in portrait format to be used. Seek guidance for illustrative material.
· Black word-processed print to be used. The font chosen for the main body of the finished work should be easy to read. eg Times New Roman, Arial, Calibri.
· Text should be double-spaced (or 1.5 spaced) and printed one side of page only.
· For successful binding, the left margin on each sheet should not be less than 40 mm, other margins to be not less than 20 mm.
· Pages should be numbered consecutively throughout the main text (including appendices) Numbering should be bottom centre of each page, approximately 10 mm away from the edge.
· Each chapter should begin on a separate page.
· Illustrative material should be arranged near the appropriate text. Where possible, avoid the use of folding/oversized material.
· Tables or figures should be given a number, a title and a source if not derived from original research work. As with other illustrative material, they should be placed as close as possible to any text reference and referred to by their number in the text.
8.2.4 Assessment
The breakdown of marking criteria is shown in the Group Project Module specification in the Student Handbook. In arriving at an assessment mark, a number of factors will be taken into account by the markers, some of which are listed below, however, for this project the assessment will not be as rigorously applied as for the final Degree Dissertation. Use the information below as a guide.
· The original aims and objectives of the Project were clear, satisfactory at honours degree level, and had been fully met.
· The relationship between the current and previous research in the topic area was defined, with similarities and differences considered.
· The methodology employed was appropriate and applied in a suitable manner. Where knowledge was gathered from external sources valid and reliable methods were used. Critical use was made of published work and source materials.
· Due credit was given to previous workers for ideas and techniques used by other authors. There is a clear appreciation of the relationship of the special theme to the wider field of knowledge. Where a conceptual framework was used/developed, use was made of it in a systematic way.
· The document was organised in a logical manner and the style is attractive.
· The ideas presented and software developed display original and creative thought.
· The work opens up possibilities for future projects and research.
· A working system that meets the requirements laid down in the project specification was developed.
· The system produced was evaluated through the application of appropriate test data.
· The challenging nature of the project.
· The degree to which the project is original, creative and interesting.
· The quality, reliability, timeliness and maintainability of the deliverable.
The more of the following your report has, the lower the mark it will attract:
· errors of fact;
· vague aims and objectives;
· vague requirements for artefacts;
· unexplained or ill-judged design decisions;
· little or no analysis, solely descriptive;
· trite conclusions;
· misinterpretations of literature;
· development of poor quality artefacts;
· work that was facile;
· little evidence of work done by the student;
· spelling mistakes, poor grammar, odd structure, crazy layout.
Some of the above are mutually dependent – a project with weak practical outcomes is likely to be weak on conclusions as well.
8.2.5 Plagiarism
Plagiarism is defined as the unacknowledged use of another's work as if it were one's own. To illustrate, if you when you are evaluating the state of the art of a subject area you come across a really good section in a textbook or research journal that made a salient point and you copied it without acknowledgement, that would be plagiarism. So using the words of another author, or even using figures from elsewhere, without saying where they came from is a serious academic offence. What you are doing really amounts to theft of another person's intellectual property and deception in trying to pass it off as your own work. This is regarded as very serious.
The following are clear examples of plagiarism:
· Using directly quoted material without placing it within quotation marks (or indenting and single spacing the quote);
· Paraphrasing the work of an author and attempting to pass it off as your own by not including a citation;
· Submitting the work of someone else as if it is your own.
· Incorporating a piece of program code within your solution without reference to the source.
· Inability to defend written work in a viva situation.
You can, of course use the ideas, program code and data of others - there is no problem if you acknowledge the source. That is why the referencing system is so important. See Appendices 4 and 5 for more detail on this.
Plagiarism is a serious matter and will not be tolerated. Disciplinary action will be taken against transgressors.
8.2.6 Handing in your Project Report
· Students must submit two copies of their project documentation. A CD/DVD/memory stick with source code, installation instructions etc. should also be supplied if required, one with each copy of the document.
· Each copy of your report should have a signed copy of the Declarations and the Form of Consent. These should be included just after the title page. A copy of the forms can be found in Appendices 1 and 2.
· All projects must also be submitted through TurnItIn.
APPENDIX 4: REFERENCING CONVENTIONS
When you refer to a piece of work in an essay, report, program or academic paper, you must give adequate bibliographic information to allow the reader to trace the original document. (For note on Plagiarism See Section 8.2.5). So, if you wish to incorporate points made by another author or figures derived from a survey or report, acknowledge the sources used in the text of your project and give full details of the source in the reference list at the end of your work.
A reference is usually in two parts:
1. a marker at the end of the text being quoted or referred to, and
2. a complete citation in either a footnote or, more usually in computer science, collected with other citations in a “References” section at the end of your work.
Note sometimes you will find references at the foot of the page rather than at the end of the work but it is simpler to provide an alphabetical list at the end of the project.
Citations use a sequential number scheme, with the citation number enclosed in square brackets corresponding to the appropriate reference provided at the end of the document.
Example :
In your work :
...... as Smith [14] has shown ......
...... blue has been shown [14] to be the best ......
In the Reference at the end :
[14] A. Smith, A Book Title, 2nd ed., Wiley, 2002
The numbering should be sequential as citations are used, the first reference used in the document should begin with one, the second is two, etc. If the same reference is used in the document then you may repeat the previously assigned reference number e.g.
In your work :
….. from Smith [1] we find that ……
….. Jones et al [2] also states …….
….. it has been shown [1] that ……
….. which matches similar findings [3] …..
…. other research [1][2][3] has proven …..
In the Reference at the end :
[1] A. Smith, A Book Title, 2nd ed., Wiley, 2002
[2] D. Jones, B. Thomas, Another Book Title, O’Reilly, 2004
[3] K. Smith, Yet Another Book Title, Chichester: Wiley, 2006
When using a reference you don’t explicitly need to specify the author(s) name, but specifying the author’s name can increase readability. Also, if many authors contributed to the book, paper, etc, then identify the first author and use “et al” to indicate that there were many contributors.
In your work :
….. it has been shown [2] that ……
….. Jones et al [2] also states …….
Quotations should be placed in quotes, italicized and tabbed from the edge, with a clear reference to the source. In addition, for clarity it is recommended that a single blank line be added before and after the quotation
For example:
“It becomes clear that, in most cases, the goal of finding out about people through interviewing is best achieved when the relationship of interviewer and interviewee is non-hierarchical and when the interviewer is prepared to invest his/her own personal identity in the relationship” Bloggs et al [6]
The author’s name (Bloggs et al) in the above is optional but is included for readability.
When should a citation be used?
1. All direct quotes must be cited.
2. Even when you have translated an author’s words into your own (which you should make every effort to do), you must still give them credit by including a citation. When an entire paragraph of material is based on one author’s ideas, you only need place one citation at the end of the paragraph. Exceptions to this rule follow in (3) and (4).
3. All statistics that are cited require a citation immediately following the sentence in which they appear.
4. All historical events and dates mentioned require a citation.
5. References should be included for all websites used.
Reference Information and Structure
All references should be added to a “References” section included towards the end of the document.
The details which need to be included in references (author, title, etc) depend on the type of publication you are citing (articles, books, etc). For the commonest types of publication, the examples below show the information you should give, as well as the correct use of italics and punctuation.
Accessed from:
http://www.swan.ac.uk/lis/help_and_training/htmdocs/bibliographic_referencing/numeric_referencing_examples.asp
There are a number of referencing systems but the Numeric system is the system that MUST BE USED FOR THE Project. For a full explanation and examples of the numeric systems see Appendix 5.
APPENDIX 5: NUMERIC REFERENCING SYSTEM
Numeric Referencing Guidelines
The details which need to be included in references (author, title, etc) depend on the type of publication you are citing (articles, books, etc). For the commonest types of publication, the examples below show the information you should give, as well as the correct use of italics and punctuation.
Accessed from:
http://www.swan.ac.uk/lis/help_and_training/htmdocs/bibliographic_referencing/numeric_referencing_examples.asp
Author(s) or editor(s) of book | Title of book: and sub-title if there is one (in italics) | Edition (if not the first) | Place of publication | Publisher | Year of publication
Author(s) and Title should be given as they appear on the title page inside the book. (The front cover may have less detail.) Information such as the year, place of publication and publisher is usually on the back of the title page.
Edition should be abbreviated: 2nd ed.
Place of publication is usually a town or city. For U.S. place names, give the two-letter state abbreviation as well.
[1] W.-K. Chen, Linear Networks and Systems. Belmont, CA: Wadsworth, 1993.
[2] S. Lin and D. J. Costello, Jr., Error Control Coding: Fundamentals and Applications. Englewood Cliffs, NJ: Prentice Hall, 1983.
[3] G. C. Clark, Jr. and J. B. Cain, Error-Correction Coding for Digital Communications. New York: Plenum Press, 1981.
[4] R. Steele and L. Hanzo, Eds., Mobile Radio Communications, 2nd ed. Chichester: Wiley, 1999.
[5] M. A. Soderstrand, W. K. Jenkins, G. A. Julien, and F. J. Taylor, Eds., Modern Applications of Residue Number System Arithmetic to Digital Signal Processing. New York: IEEE Press, 1986.
Chapter in a Book
Author(s) of chapter | "Title of chapter" (in quotes) | in Title of book (in italics) | Edition (if not the first) | Editor(s) of book | Place of publication | Publisher | Year of publication | Pages covered by chapter
[6] G. O. Young, “Synthetic structure of industrial plastics,” in Plastics, 2nd ed., vol. 3, J. Peters, Ed. New York: McGraw-Hill, 1964, pp. 15-64.
[7] S. Godsill, P. Rayner, and O. Cappé, “Digital audio restoration,” in Applications of Digital Signal Processing to Audio and Acoustics, M. Kahrs and K. Brandenburg, Eds. Boston, MA: Kluwer Academic, 1988, pp. 133-194.
[8] J. K. Hao and R. Dorne, “Study of genetic search for the frequency assignment problem,” in Artificial Evolution: European conference, AE 95, Brest, France, September 4-6, 1995 : selected papers,” J.-M. Alliot, Ed. Lecture Notes in Computer Science, 1063. Berlin: Springer-Verlag, 1996, pp. 333-344.
Author(s) of article | "Title of article" (in quotes) | Title of Journal (in italics) | Volume number (and issue number if there is one) | Pages covered by article | Date of Publication
Date of Publication should include the month or season if it appears on the journal: e.g. Feb. 1987; Winter 2000; Mar.-Apr. 1963
[9] G. Strang, “Wavelets,” American Scientist, vol. 82, pp. 250-255, 1994.
[10] I. S. Qamber, “Flow graph development method,” Microelectronics Reliability, vol. 33, no. 9, pp. 1387-1395, Dec. 1993.
[11] F. Bonomi and K. Fendick, “The rate-based flow control framework for the ABR ATM service,” IEEE Network, vol. 9, pp. 25-39, 1995.
[12] E. H. Miller, “A note on reflector arrays,” IEEE Transactions on Antennas and Propagation., to be published.
Article from Conference Proceedings (published)
Author(s) of article | "Title of paper" (in quotes) | in Title of proceedings (in italics) | Location and date of conference | Pages covered by article
[13] R. Bauer and J. Hagenauer, “Iterative source/channel-decoding using reversible variable length codes,” in Proceedings of the IEEE Data Compression Conference (DCC), Snowbird, UT, Mar. 2000, pp. 93-102.
[14] A. K. Salkintzis, C. Chamzas, and C. Koukourlis, “An energy saving protocol for mobile data networks,” in International Conference on Advances in Communication and Control (COMCON 5), June 26-30, 1995, pp. 107-113.
Paper Presented at a Conference (unpublished)
Author(s) of paper | "Title of paper" in quotes | presented at Title of conference | Location and date of conference
Unpublished papers are often made available as reprints to conference delegates but do not appear in collected conference proceedings, so no pagination should be given.
[15] F. Comellas and J. Ozón, “An ant algorithm for the graph coloring problem,” presented at ANTS ’98 – From Ant Colonies to Artificial Ants: First International Workshop on Ant Colony Optimization, Brussels, Belgium, Oct. 1998.
[16] L. Gao, J. Kurose, and D. Towsley, “Efficient schemes for broadcasting popular videos,” presented at the 8th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV ’98), Cambridge, UK, July 1998.
Author of thesis | "Title of thesis" (in quotes) | Qualification and type of report | University/Institution | Year of award
Qualification should be abbreviated as Ph.D., M.Phil., etc. The type of report (e.g. thesis, dissertation, etc) should be given as it appears on the document as the terminology may vary between countries. It is helpful to add the country unless the university is particularly well-known.
[17] E. F. Mastrovito, “VLSI architectures for computation in Galois Field,” Ph.D. dissertation, Linköping University, Sweden, 1991.
[18] A. Chini, “Multi carrier modulation in frequency selective fading channels,” Ph.D. dissertation, Carleton University, Canada, 1994.
[19] Y. W. Kim, “Study and implementation of system synchronization for DAB (Digital Audio Broadcasting),” Masters thesis, Korea Advanced Institute of Science and Technology, Korea, 1996.
[20] J. G. O. Moss, “Spread spectrum technologies for future communication systems,” D.Phil. thesis, University of Oxford, 1998.
Author(s) of report | "Title of report" in quotes | Series title and number (if applicable) | Place and date of publication
Technical reports are often not formally published and may not have clear publication details. Give as much information as you can so your readers can obtain the report if they wish.
If the place of publication is obvious from the series title there's no need to repeat it at the end.
[21] M. Krunz and S. K. Tripathi, “Scene-based characteristics of VBR MPEG-coded video traffic,” University of Maryland, CS-TR-3573, 1997.
[22] J. H. Stott, “Phase noise in OFDM: Further insights, including the use of weighting functions,” BBC, R&D Department, Technical Note no. R&D 0166(94), Dec. 1994.
[23] A. Dan, P. Shahabuddin, D. Sitaram, and D. Towsley, “Channel allocation under batching and VCR control in movie-on-demand servers,” IBM Research Report, 1994.
[24] International Telecommunications Union, “Terrestrial digital multimedia/television broadcasting system development in China,” ITU-T Document 6E/50-E, Geneva, Mar. 26, 2001.
Name of the organization which produced the standard | "Title of standard" (in quotes) | Catalogue code or number of standard | Date of publication
Standards are frequently issued in draft and revised versions. Make sure you cite all the catalogue/numbering and date information exactly as it appears on the document.
If the name of the organization appears in the catalogue code or number of the standard it can be abbreviated.
[25] International Standards Organisation, “Information technology – Generic coding of moving pictures and associated audio information: Video specification,” ISO/IEC 13818-2, Nov. 1994.
[26] Federal Communications Commission, “Code of Federal Regulations,” Title 47, Ch. 1, Part 73, Radio Broadcast Services. Secs. 73.683, 73.684 and 73.699.
[27] European Telecommunications Standards Institute, “Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers,” ETSI EN 300 401 v1.3.3, May 2001.
[28] Institution of Electrical and Electronic Engineers, “Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” IEEE Draft standard 802.11 D3.1, Apr. 1996.
Author(s) of the patent | "Title of patent" (in quotes) | Issuing country/organisation and number of the patent | Date of filing
[29] L. Idoumghar, “Using a hybrid genetic algorithm to solve the frequency assignment problem,” Patent TDF, N. 01 06 885, May 2001.
[30] Z. Yang, “Terrestrial digital multimedia/television broadcasting system,” P.R.China Patent 00 123 597.4 filed Aug. 25, 2000, issued Mar. 21, 2001.
[31] S. Kawa, K. Kiyoshi, and S. Takeshi, “Route bus service controlling system,” U.S. Patent 4 799 162, Jan. 1989.
Author(s) | "Title of document" (in quotes) | Type of document | Date (if applicable)
The type of document might be an unpublished manuscript, e-mail or private correspondence, etc. Clearly these are not available to your readers but you should still give as much detail as you can.
[32] B. Chen and C.-E. W. Sundberg, “Adaptive multicarrier modulation for IBOC-AM,” Unpublished work.
[33] R. Cupo and M. Shariat, “All-digital AM system architecture,” Private communication, May, 1998.
Author(s) | "Title of source" | Organization/Publisher/Date | [Online] | Available: access information | [Accessed: Date of access]
An online source may not always contain clear author or publisher details. When you cite an online source try to describe it in the same way you would describe a similar printed publication. If possible, give sufficient information for your readers to retrieve the source themselves.
The access information will usually be just the URL of the source. If the item is only available by e-mail, ftp or some other method, include a brief mention of how to obtain it.
As well as a publication/revision date (if there is one), the date of access is included since an online source may change between the time you cite it and the time it is accessed by a reader.
[34] T. Rahkonen, “Analysis of analog circuits using Volterra series,” University of Oulu, Oulu, Finland, 1999. [Online]. Available:
http://www.ee.oulu.fi/~timor/DCourse/Chp1_2.pdf. [Accessed: Sept. 14, 2002]
[35] S. McCanne and S. Floyd, “The UCB/LBNL network simulator,” 1997. [Online]. Available: http://www.mash.cs.berkeley.edu/ns/. [Accessed: Jan. 23, 1999]
[36] Advanced Television Technology Center, Inc., “ATTC introduces RF data capture project,” Press release, Mar. 2000. [Online]. Available: http://www.attc.org/RFCapture.PDF. [Accessed: Mar. 15, 2001]
[37] “AlphaCom Communications introduces VMSK technology,” The Business Journal Online, May, 2000. [Online]. Available: http://www.business-journal.com/LateMay00/Alpha.html. [Accessed: May 2, 2000]
[38] “A ‘layman’s’ explanation of Ultra Narrow Band technology,” Oct. 3, 2003. [Online]. Available: http://www.vmsk.org/Layman.pdf. [Accessed: Dec. 3, 2003]
[39] European Telecommunications Standards Institute, “Digital Video Broadcasting (DVB); Implementation guidelines for DVB terrestrial services; transmission aspects,” ETSI TR-101-190, 1997. [Online]. Available: http://www.etsi.org. [Accessed: Aug. 17, 1998]
[40] S. J. Salamon, “DTV receiver performance studies,” presented at the 49th Annual Broadcasting Symposium, IEEE Broadcasting Technology Society, Sept. 24, 1999. [Online]. Available: http://www.attc.org/BTS_Rx.PDF. [Accessed: Jan. 18, 2000]
[41] P. Karn, “General-purpose Reed-Solomon encoder/decoder in C,” Jan, 2002. [Online]. Available: http://www.ka9q.net/code/fec/. [Accessed: Oct. 8, 2002]
[42] A. Harriman, “Compendium of genealogical software,” Humanist, Jun., 1993. [Online]. Available e-mail: HUMANIST@NYVM Message: get GENEALOGY REPORT. [Accessed: Jun. 8, 2003]
