Comp 1181-project report structure

Undergraduate Computing Projects

Structure of the Project Report

1. AimsThe aims of this lecture are:

To familiarise the student with the overall task of writing up an undergraduate computing project

To present the particular report elements that must be included to comply with the style set by the School of Computing and Mathematical Sciences.

2. Objectives and Learning OutcomesAt the end of the lecture, students should:

Be able to list and describe the elements to be included in the write-up of an undergraduate computing project.

Be able to give an example breakdown by chapter for a project report. Be able to identify areas of the write-up that students commonly find difficult and to list

actions that they can take to overcome or reduce the difficulties.

3. IntroductionFor many students, the project report (we shall often refer to it as a dissertation) will be the longest single piece of writing that they have ever attempted. For some, the idea of writing around 8,000 words may seem a very daunting prospect. Students who are not familiar with the rules of English grammar are likely to experience problems with expressing themselves clearly in a written form, particularly with the correct usage of words and with getting the structure of their writing grammatically correct. This and subsequent lectures will give you a good idea of the task ahead of you, and will provide you with valuable information about:

• Writing style, writing aids, grammar, and ways to make the task of writing up your project as painless as possible.

• How to organise your dissertation and the required elements that must be included.• The presentation of the dissertation: text formatting, how to include figures, charts, tables

etc., citing references and so on.

We start our discussion by answering the two most frequently asked questions: “How much should I write?” and “When should I start my write-up?”

3.1 How Many Words?Experience shows that if left to their own devices, students will produce project reports with anywhere between 6,000 and 15,000 words in the main body of the report (excluding appendices etc). On the other hand, it would be difficult to specify an exact number of words required. The number of words will often vary depending on the type of project undertaken and the writing style of the author. Seeking advice from other academics in the field, we can note the following points (Cornford, T. and Smithson, S., 1996):

School of Computing & Mathematical Sciences, University of Greenwich 2001 1


• As a student on a formal course you should have clear guidance as to the expected length of a report.

• In the case of an undergraduate project (this should be) perhaps in the region of 6,500 to 8,000 words.

• Whatever the limit is, you should be clear whether it applies to the whole document, or just to the main body of the report (i.e. excluding the abstract, table of contents, bibliography, appendices etc.).

Taking these points into account and based upon experience, the following guidelines will apply to all undergraduate computing projects submitted within the School of Computing and Mathematical Sciences.

These guidelines have been set to enable students to write up their projects both completely and competently. There may be occasions when the student finds it necessary or desirable for the sake of completeness, to exceed the upper limit. In such cases, advice from the supervisor should be sought first, in order to save the student any unnecessary effort and time. The word count of a submitted project report may also be less than the minimum recommended. This may be for a number of reasons. Experience shows that reports with a lower than recommended word count do not generally contain a sufficiently detailed account of the work carried out and it is difficult therefore to award high marks to them.

3.2 When Should I Begin?If you decide to write up your project as a single task at the end of the project then its fairly safe to say that you will never have sufficient time in which to compose a project report that does full justice to the work that you have carried out on your project. Writing up should be considered as an ongoing task that increases in intensity as the project draws to a close. If you have taken a systematic approach to your project and followed the guidelines given in earlier lectures, such as breaking the project down into small, manageable work products, keeping a project notebook etc., then you should be able to write up each step of the project as it is completed. Each step will then become a section to be included in the final report. One of the earliest efforts at writing for example, will be the writing up of the results of the literature survey in a literature review.

The following points emphasise the need to begin writing up stages of the project at the earliest opportunity.


Guidelines Concerning the Word Count for Reports forUndergraduate Computing Projects

1. The number of words in the main body of the report (i.e. excluding the abstract, table of contents, bibliography, appendices etc.) should be between 7,000 and 10,000 words.

2. This limit applies to the main body of the report only.3. No marks will be deducted because the word count lies outside the

recommended limits.


Every year, on the day that projects are due to be submitted, the computing laboratories at the University of Greenwich are full with students desperately trying to finish typing up their project reports. The volume of demand for printing 8-10 thousand word documents (two copies of each report are required) has a marked effect on the performance of the network printers, often resulting in print queues with a waiting time of four hours or worse (ten hours has been known!). Whilst the technical staff do their best by taking printers from elsewhere to provide students with additional printing resources, it is a wise student who anticipates these eventualities and plans the production of their project report to avoid them.

4. Structure of the Project ReportSelect just a few of the text books that you are currently using and look at the first few pages of each one. You will find that the overall structure of each book is almost identical. In the same way, published papers in journals, or papers submitted to conferences, will also conform to a predetermined structure. Reports for undergraduate computing projects should adopt a common standard for their overall structure. The required elements of a project report are given below and must be included in every project report, except where denoted as optional, and in the order given. We discuss the content and structure of each report element below.


If you put off writing up preliminary results, then you will find it increasingly more difficult to begin the process of writing-up.

Write regularly so that writing becomes a commonplace activity; little and often is better than nothing at all.

Try to take an interest in using language to communicate and try to improve your ability as a writer.

Seek out any help available - supervisor, library staff, examples of good writing in texts and journals, etc.

The project report is the basis on which the work that you have done towards your project will be assessed; you will be judged on the quality of your write-up as well as on the work completed.

You will need considerable time once you have completed the project work itself, to compose the final report.

Remember:-

No allowance in the project submission requirements will be made on the basis of long printer queues! Allowance will only be given if the computing facilities are made unavailable due to technical problems.


4.1 Title PageThe organisation of the title page will depend upon the style of project cover adopted by the School, but must conform to the ‘house style’ set by the School. It will contain the following information:

project title author programme of study year of submission.

An example layout is shown here:


Elements of a Project Report

Title PageAbstractPreface …………………….optionalAcknowledgementsTable of ContentsList of Tables………………optionalList of Figures……………...optionalBody of Report List of ReferencesBibliographyAppendicesGlossary……………………optional

<Title of Project>

<Author's name>

<Year of Submission>

<Word Count>

A dissertation submitted in partial fulfilment of the requirements for the University of Greenwich’s Bachelor of Science Degree in <Title of Degree Programme>


The title page should also show a word count of the number of words in the main body of the report, and the following statement inserted at the bottom of the page:

A dissertation submitted in partial fulfilment of the requirements for the University of Greenwich’s Bachelor of Science Degree in . . .

4.2 Abstract

"The concentrated essence of a larger whole."

Blaxter et al. (1996) define the function of an abstract as to ‘summarise briefly the nature of your (research) project, its context, how it was carried out, and what its major findings are’. An abstract tells the reader what to expect in the report. The Abstract should not:

• Discuss the background to the project in detail nor the reasons why you thought that the project was a good idea. This should be included in a separate introduction.

• Include any citations, that is, references to other works.• Be structured as a contents listing.• Include jargon and acronyms.

An abstract usually consists of a single paragraph of between 100 and 200 words. Since it needs to convey what is actually in the project, it should be one of the last things that you write. Look at some abstracts for articles and get a feel for good (or bad) presentation.

4.3 Preface

"A statement or essay, usually by the author, introducing a book and explaining its scope, intention, or background."

The majority of project reports do not need to include a Preface. You should include a Preface only when you think that it is important to inform the reader of any of the following observations that are not part of the report proper, e.g.

explanatory remarks concerning the project and the way in which it was carried out practical constraints that were not foreseeable and that adversely affected the final

outcome


The Abstract is usually the first thing that the examiner will read. It tells them in brief what your project is about. A poorly constructed Abstract will create a bad first impression that may be hard to undo if the rest of the report is not up to a high standard.


4.4 Acknowledgements

"An author's expression of thanks, at the beginning or end of a book, to those who have helped him or her".

In the case of a scholarly publication such as a report that constitutes the write-up of an academic project, help is interpreted as academic guidance or material contribution to the project. It does not include the type of support associated with friends, family and religions.Acknowledgements may include:

the student's academic supervisor person or persons working for companies, organisations or institutions that have provide

material help, access to resources, or concrete ideas

Acknowledgements should not include:

friends family spiritual sources

4.5 Table of ContentsThe Table of Contents should be a list of chapters and sections and their page numbers. In addition to showing the location of each chapter in the main body of the report, the Table of Contents should list all the report elements that are included in the report, together with the page numbers where they can be found. The sections are arranged in the same order as they occur in the text. The Table of Contents enables the reader to see the structure of the report, and to turn to the page of any section required. It should not be confused with an index, which is to be found at the end of a book or document. An index is not normally required for a dissertation.

Its possible that you might decide to divide a chapter, say chapter 4, into major sections numbered 4.1, 4.2 and so on, and then to divide a section, say section 4.1, into sub-sections numbered 4.1.1, 4.1.2, and so on, and then to divide section 4.1.2 further into 4.1.2.1, 4.1.2.2 and so on. Should you include all these levels of subdivision in the Table of Contents? If the purpose of the Table of Contents were to be the complete listing of every section of the report then the answer would be yes. However, doing this could generate a large Table of Contents with lots of different levels and the result could be quite overwhelming. In deciding how many levels to include in a Table of Contents, you should bear in mind that the purpose of the Table of Contents is to direct the reader quickly and effectively to parts of the report that they may wish to read first, or indeed to read once more. In this way, the Table of Contents acts as an index.

4.5.1 Generating a Table of ContentsA Table of Contents can be automatically generated by a word processor. In MS Word 97 for example, selecting Insert and then Index and Tables leads to a tabbed option called Table of Contents. This option allows you to select different formats for a Table of Contents. You should avoid using formats that show too many different fonts and font styles between levels.



Adopt or create a straightforward style (you can modify the formats presented to you) with plain font styles without bold and italic attributes. Use a simple dot leader. The auto-generation of a Table of Contents depends upon you using the predefined headings from the style menu. You can choose an appropriate style from the Style Gallery in Format, and then modify the font style for separate headings using the Style option in Format. It is worth practising this until you achieve the desired font styles and effects for the Table of Contents.

4.6 List of FiguresLike a Table of Contents, a List of Figures provides an index to all the figures that have been included in the main body of the report. For figures included in the appendices, a separate list should be created. Details of how to include and format figures, tables and graphics in a project report are given in a later lecture. For now, we are concerned with how to create a List of Figures.

There are two approaches that can be adopted for numbering the figures that appear within the main body of the report. The first simply assigns an integer to each figure, in increasing sequence through the report. This method is appropriate where figures are roughly evenly distributed through chapters and it is not important to signify by the numbering, which chapter a figure belongs to. The second method numbers figures within chapters.

4.6.1 Method One

Figure 1 ….. , Figure 2 …... , Figure 3 ….. , and so on. The numbers do not indicate any particular chapter number.

4.6.2 Method Two

Figure 1.1 ….. , Figure 2.1 ….. , Figure 2.2 ….. , Figure 3.1 ….. , and so on. Thus Figure 1.1 belongs to Chapter One and is the only figure in this chapter. Chapter Two on the other hand contains two figures denoted by Figure 2.1 and Figure 2.2.

4.7 List of TablesIn the same way that we can create a List of Figures, we can create a List of Tables (come to think of it, we could create other sorts of Lists if we felt it was justified to do so - see List of Abbreviations at the end of these notes). Again, we choose to adopt a common numbering system, e.g.

Table 1, Table 2, . . . Table n, numbering each table in turn, or


Like the Abstract, the Table of Contents will be one of the first things that the examiner looks at. It is usually consists of at least two pages of structured and stylised content. It should therefore appear clear and uncluttered, enabling the reader to find their way through the contents quickly and easily.


Table 2.1, Table 4.1, Table 4.2 etc numbering within chapters.

4.8 List of AbbreviationsWhere a project report includes a number of abbreviations, particularly ones that the reader may not be familiar with, then these can be collected together for the reader in a suitable list. The list of abbreviations in the area of data and computer communications for example, continues to grow. Whilst most readers would understand the abbreviation LAN for 'local area network', not everyone might recognise or remember exactly what ADSL for example, is an abbreviation for.

4.9 Main Body of the ReportThe main body of the report begins with Chapter One which follows immediately after any Lists. The purpose of the main body of the report is to describe the work carried out in the project along with the context setting for the project. For this reason, the main body of the report should be organised in a way that allows the project report to ‘tell a story’; it should therefore have a beginning, a middle, and an end. The beginning would normally introduce the project, explain the background to it and set the context for the ensuing work. The middle part would describe the work that you carried out and the manner in which you carried it out. The end part of the main body of the report should summarise what has been achieved and state any logical conclusions arising from the work carried out. It is also the place to critically evaluate the product as well as your own performance in carrying out the project.

Clearly, much of the assessment of your project will depend on how well you document your efforts and also the software product that you have built. The writing-up of work carried out is very often a major stumbling block for students. A poor write-up will almost certainly attract a low mark for the project report. The correct use of appropriate methods used in building and testing the product is also assessed through the documentation included in the report which means that as much as 60% of your project marks may be affected by the quality of your write-up.

There is no reason why any student should not produce a project write-up to a reasonable standard. You must follow the guidelines given and be prepared to discuss the write-up fully with your supervisor. Some initial simple dos and don'ts include:


Aside from the use of poor English and proof-reading, the main reasons why students produce poor write-ups are:

not attending project lectures not following the guidelines given for producing a project report not carrying out a proper literature survey and therefore not including

a literature review in the report not including a component of critical analysis in their descriptions and

observations not discussing the write-up with their supervisor starting the writing-up too late just not being bothered


Do make sure that you describe what you have actually done during your project and don't assume that just because you know what you did that anyone else will - they won't unless you tell them in your write-up.

Do include work from authors to substantiate your own work; you can present their ideas and arguments in your own words and even include short quotes where appropriate, but

Do give proper acknowledgement for someone’s work that you are using in your project - you do this by citing the source whenever you refer to it in your writing and giving the full bibliographic reference for each source in the Bibliography.

Don’t include whole chunks of text from other works - paraphrase them in your own words and cite the reference.

Don't use bullets; bullets are used as a presentation aid to summarise something that would otherwise take one or more paragraphs to explain. Your write-up should be concerned with taking great care to explain each point, concept, argument etc that you include. Introduce the items for discussion separated by commas in a single sentence and then devote a paragraph to describing each item in turn. An alternative approach where there are only a few items, would be to create a short numbered list before discussing each item in turn.

Don't give long lists; these are generally not helpful to the reader. You should decide whether to include the full list in an appendix, or if you think that it is important to show all list elements in the main body of the report then put them into a table. This format gives a much better appearance and does not interrupt the reader's flow, allowing them to skip to the table's contents at their own discretion.

4.9.1 Structure of the Main BodyNow that we have some idea of what the main body of the report should contain, we can focus on certain specific items that would normally be included. These are:

An introductory chapter. A literature review. Project objectives, activities and methods. A full description of the work done. A presentation and summary of the results of the project. A conclusion.

4.9.1.1 The IntroductionThe purpose of this chapter is quite naturally, to introduce the project to the reader. It should therefore describe briefly what the project is about. The introductory chapter therefore serves two purposes, to introduce the project to the reader and to summarise what the project sets out to achieve. The contents should include:

1. The scope of the project i.e. the area covered by the project.

Use this section to explain clearly which aspects of the problem area will be covered in the project and the expected depth of treatment for each aspect. If necessary, state clearly which are the aspects of the problem area that the project will not be concerned with and why not. Take the opportunity to say briefly how you arrived at the scope for your project - this is in a sense an informal feasibility study in which you assess the proposed



project on characteristics such as depth of investigation and literature search, complexity of the problem, use of new and/or challenging technology etc.

2. A background to the project explaining the origin of the idea for the project and why it might be considered an interesting and important topic.

By 'interesting' we mean that the topic is of significance and therefore the project is worth doing. This infers that any project proposed should have some merit associated with it rather than being done just for the sake of it. By talking about how the idea for the proposed project arose, you are putting forward the case for carrying out the project as well as providing the problem context for the rest of the report.

3. A description of the problem area.

It is a good idea to provide the reader with an overview of the problem that the project seeks to address, before they start to read the literature review. For example, if you propose to design and implement a database application that you will then link to a web page then you are designing an information system that will be distributed using a form of client-server technology. The relevant problem areas are:

• how to design information systems• how to design databases• how to use a specific DBMS• how to provide a database query facility• how to implement relevant client-server technology

4. A ‘roadmap’ of the project e.g. Chapter 2 explains ... Chapter 3 discusses ...

4.9.1.2 Literature ReviewThe literature review is compiled from the results of the literature search. The information acquired from the literature search - books, photocopied articles, notes that you have made from time spent in libraries etc. - is sorted and analysed for its immediate relevance and put together in concise form to provide:

1. A summary evaluation of literature relevant to the project area.2. An examination of theories, concepts, approaches, methods and techniques that fall

within the general topic area with an assessment of their relevance to your particular project area.

3. An explanation of how you will apply any of these in your project.

Writing a good literature review can be a difficult task if you don't have a clear idea of what is required. To help with this, we provide answers to some frequently asked questions.

How long should the Literature Review be?

This is a bit like asking 'How long is a piece of string?' because there is no fixed answer. However, as a guide, you could aim at around 1500 words as an average figure. Using the required formatting of one and a half lines spacing between lines, and one inch margins all



round, and adopting the font Times New Roman 12-point, you should find that you achieve on average 13 words per line and up to 28 lines per page, not allowing for sub-headings and white space. This means that 1500 words will fit onto between 4 and 5 pages. The inclusion of diagrams will of course increase the number of pages.

How much detail should I include in a Literature Review?

It is not necessary to give detailed explanations of particular subject areas nor methods and techniques. These can be explained in greater detail elsewhere in the project report. A literature review as the name suggests, reviews concepts, ideas etc, presenting them in essence rather than in detail.

What form should the Literature Review take?

The simplest way to approach writing a literature review is to devote a single chapter to it and to treat it as a separate but not entirely independent piece of work. In other words, you can write the literature review without worrying about other chapters in the report. You only need to think about referring the reader from a point in the literature review to another place in the report where the point occurs within the project proper. These links or forward references can be finalised in the final draft of the project report when page numbers won't change. Apart from this, you can concentrate on summarising relevant concepts that you have read about, and explaining how they relate or don't relate to your project.

Does this mean that I don't need to cite references anywhere else in the report?

No, not necessarily. The literature review is not all-embracing as far as citing references from relevant sources is concerned. In some cases the nature of the project may be such that technical sources are more appropriately referred to as and when the need arises. For example, in a chapter on design, we might be discussing the design of a particular algorithm or a collaboration of objects or perhaps some particular aspect of database design. It would be appropriate as part of the design discussion to refer to the work and ideas of other authors. These more specific design elements might not be included in a literature review that is more likely to summarise concepts and ideas rather than to explain them in great detail.

Should I include something about each book and article that I have read?

Definitely not! A literature review is not the same as a book review. It is a cohesive account of the related concepts and ideas found in a selected set of works.

4.9.1.3 Objectives, Activities and MethodsThe purpose of this chapter is to state in terms of high-level objectives precisely what the project sets out to achieve and the methods adopted in order to satisfy these objectives. The project objectives should already have been specified in the Project Proposal. If there have been no changes to these, then they can be copied, otherwise the revised set of objectives should be inserted together with an explanation for the changes.

Each objective will cover a part of the overall project and thus there will be one or more methods and/or associated techniques that will be used in order to carry out the activities associated with the achievement of each objective (the activities should have been specified



with the objectives in the Project Proposal). We will give two examples by way of illustration.

Consider again, the example project proposal given in the lecture Writing a Project Proposal. We will concentrate on Objectives 1 and 4 for the purposes of our illustration. The activities for Objective 1 have been amended to include the use of questionnaires.

In Objective 1, the activities "Hold interviews with consultants and practitioners working in the area of computer auditing and software compliance and send questionnaires to a sample of IT managers in medium-to-large sized business organisations" require that appropriate methods and techniques are investigated for the design of suitable questionnaires and for interviewing. These are fact-finding techniques that are described in most books dealing with systems analysis, but the degree to which they are used may determine whether more rigorous statistical approaches and techniques are needed in order to provide accurate and useful data for analysis.

Objective 2 deals with the analysis, design and implementation of a complete database application and therefore appropriate methods and techniques must be adopted for each stage of development. It might be the case that a well-defined methodology is considered that embraces the whole development life-cycle. It is necessary therefore, to consider different development approaches and methods suitable to be used in each development stage.


Objectives

1. To review computer auditing software packages and to establish the distinct features that are, or can be, applied in the case of software compliance.

Activities: Read literature on the use of software for computer auditing. Survey business and business computing journals and magazines for relevant articles. Obtain trial copies of relevant software packages. Hold interviews with consultants and practitioners working in the area of computer auditing and software compliance and send questionnaires to a sample of IT managers in medium-to-large sized business organisations.

Deliverables: Section for report. 1000 – 1500 words.

2. To

3. To

4. To design and implement a database that will hold information relating to an organisation’s compliance with the laws and guidelines governing software compliance.

Activities: Analyse the information collected and draw up a requirements specification. Select appropriate methods and design and implement a database and database application to meet the requirements.

Deliverables: Requirements specification. Justification for methods selected. Analysis and design documentation. Database schema. Implementation code. Test strategy. Details and results of testing carried out. Evaluation of product.Write up a full account of each step of the design with justifications for design decisions made. Include an evaluation of the design following testing and implementation.


The decision to adopt specific approaches, methods and techniques should be discussed and the final decision justified according to whatever criteria are considered relevant to the project. Again, the student should determine relevant criteria upon Which to base a decision. Simply stating that they intend to use a particular methodology because it was covered in a lecture course or is documented in a standard textbook is not sufficient. This does not show any attempt at making a critical analysis of an important part of the project. The discussion of appropriate methods presents the opportunity to include further results from the literature search that were not presented in the literature review.

Many students appear to have difficulty with putting together a good chapter on objectives, activities and methods. Much of this has to do with the fact that they have spent little or no time in thinking about which development approach to follow or which methods are appropriate to their project. Time should be spent at the beginning of the project, particularly during the literature search, in looking at different development approaches and methodologies. This will enable you to briefly summarise with justification the choices made, for example:

4.9.1.4 Description of Work DoneHere you describe the actual work carried out by you. That is, what you did and how you did it. This is the central part of the report and there will be several chapters devoted to explaining in detail every step that you took, every decision that you made, and every problem that you encountered during the analysis, design and implementation of your software product.

Two important characteristics of the software development process will have a major impact on how you write up your description of work done:

1. Software development is an incremental process.2. Rarely, if ever, do you get it right the first time around.

So when an examiner reads your report, they should be able to read about the different attempts that you made to get something right. You should show where you made changes to your original design: a collaboration of objects, an entity-relationship model and so on, and why you made the changes. What was the effect of making the changes? It is perfectly acceptable to show something that is wrong in order to explain how to make it right.

The description of work done should focus on:

The system models that you built. The checks that you made to ensure the correctness of the models. The checks made to ensure consistency between models. The corrections that you made to the initial models. Particular problems that you had to solve in design and/or implementation. The testing that took place.



You should avoid at all costs, the temptation to include sections or chapters such as Human Computer Interaction or Testing, that simply describe a set of basic principles that have been taken straight from a book. If you wish the reader to know about these then you should refer them to appropriate sources. Of course you must discuss testing, but what the examiner wishes to read about is how you arrived at an appropriate test strategy and test plan for your software product. Explain the basis for the test data that you have derived and used. Give the results of the testing that you carried out and comment on them.

Most software applications these days have a GUI front end to them, and the majority of application development software such as MS Access, Visual Basic, Oracle and JBuilder, allow the user to build nice-looking user interface windows, without the user understanding much about the code used by the package in creating the interfaces. For this reason, it makes little sense for you to launch into the basic principles of interface design unless a) you have thoroughly researched interface design as one of your project objectives, or b) you have conscientiously applied basic principles of HCI in creating the interfaces in your product. In case (a), you will devote a significant part of your literature review to HCI and link this to the work that you did in building interfaces with specific characteristics. In case (b), you should present a screen shot or diagram of an interface that you have created and walk the reader through it, pointing out how you have applied basic principles of interface design. You should also be prepared to critically evaluate the results and comment back on the source references that you used.

By now, it should be clear that this part of the write-up is really at the heart of the report. It is your opportunity to convince the examiner that you have done the correct things and also, have done them correctly and methodically, keeping an open mind that allows you to comment critically on significant parts of your work.

4.9.1.5 Summary and Presentation of ResultsThe purpose of this chapter is to provide the reader with an 'executive summary' or quick reference of what you have done. Just as the introductory chapter includes a summary of what the project sets out to achieve, so this chapter summarises what has actually been achieved and how. Thus you present a before and after image of the project that allows the examiner to see what you succeeded in doing. This is an essential part of the project report and should not be omitted. Sometimes this part of the report appears in the concluding chapter. Our preference is for a separate chapter that presents the outcomes of the project in a summarised form.

This is a useful chapter to include before you write the concluding chapter in which you draw conclusions from the work that you have done. Summarising the key activities and deliverables in a preceding chapter will help you to organise the detail of the project as well as your own thoughts about it. A systematic approach to constructing this chapter might be to


In describing the work that you have done, you should make sure that you:

explain as well as describe, your work and your decisions; don't include descriptive extracts from books on analysis and design; can critically analysis aspects of your work rather than just accepting

that it must all be right because it says so in the book!


start with each chapter in the main body of the report and to extract from them, the main activities. For example:

Literature Review - In order to put this together, you had to carry out some form of literature search. This would be a good place to summarise the way in which you did this and the results of the search.

Systems Analysis - Summarise the methods and techniques used, comment on how fully each was used, list the models that were produced etc.

And so on. Remember, the chapter Summary and Presentation of Results is just that - summarise and present. You have already given a detailed description of what you did and how you did it in previous chapters, so this chapter will not be very long. Nevertheless it is important to include it as an 'executive summary' or quick reference of what you have done.

4.9.1.6 Conclusion In this chapter you will:

Draw logical conclusions from the work carried out. Provide an assessment of the completed software product. Assess how well you performed in carrying out the project. Propose, where relevant, recommendations on how you work might be extended by

someone else.

It is possible to draw conclusions about various aspects of the project. For example, you might have found that a particular method or technique that you used to deal with some aspect of the software design or construction, did not seem to give a 'good' outcome in some way. Why might this have been and what could you recommend for the next time? Can you conclude anything from this?

One part of the conclusion that you can always give, is a critical evaluation of the product itself. Not just "yes, it seemed to work alright" or "it worked alright but the bit where the user had to enter their name didn't work properly", but rather, an assessment of the quality of the product arising from the methods used, and the quality of the build process itself. Did you use the right methods and techniques? How did the choice of methods and techniques affect the final product? Point out any obvious limitations that you observed in building the product. Highlight things that with hindsight, you would have done differently and say why.

It is quite usual for students to spend in excess of two hundred hours on their projects over a period of six months or so. This is on average between six and seven hours per week. It is highly unlikely therefore that this experience will be a neutral one that leaves you totally unaffected and not having learnt anything about yourself and your ability to work independently. You should comment critically on your experience throughout the project, drawing out your strengths and weaknesses perhaps, and commenting on how you may have had to make changes to your normal way of doing things and so on. This should not be treated superficially but should be treated as a critical appraisal of your abilities and overall learning experience.



4.10 List of ReferencesThis should contain all published material cited in the text of the dissertation. The references should be arranged in alphabetical order by author’s surname. Sources should be cited in the main body of the report whenever you include:

Material taken verbatim, that is to say word for word, from any source, as in a quotation or other phrase.

Ideas, concepts, theories, hypotheses or opinions of other authors that you have paraphrased, that is, expressed in your own words, rather than using the exact words that the author used in their publication.

We need therefore to specify two things:

1. A standard way of citing references in the text as and when the reference occurs.2. A standard way of writing out in the bibliography, the full reference details for each

source that we cite.

Different methods have been devised over the years, but the most recent and popular one is known as the Harvard or Author-Date System. This is the one that we shall adopt for academic projects.

4.11 Bibliography

"A list of sources used as reference for the writing of a book, thesis, or the like."

"The description and identification of the editions, dates of issue, authorship, and typography of books or other written material."

The above definitions provide the two senses in which the term bibliography is used in an academic project. It provides a list of full bibliographic references of all the sources cited in the main body of the report, together with any other material that has been used in the course of the project.

Don’t seek to impress by including all the results of the literature search (as well as along list of books that you haven’t read!) A bibliography that contains everything, however remotely connected with the subject, merely indicates to the assessor a lack of intelligent discrimination on the part of the student.

The bibliography should appear at the end of the main text, before any appendices.

4.12 Appendix, pl. Appendices

"A collection of supplementary material at the end of a book."

An appendix is a place to put supporting material for your project, material whose inclusion in the main body of the text would tend to break the flow of the argument or discussion. In practice, a balance needs to be struck between putting all the technical documentation consisting of the plethora of diagrams, tables and listings that are created as a result of analysis, design and implementation into the appendices, and duplicating part or all of a



diagram, table or code fragment in the main body of the report where it provides the illustration to an explanation of how something was created and the decisions that were made. You should be guided by the following rules of thumb:

1. If the diagram, table, graphic or code fragment occupies more than half a page then it is unlikely that the whole of it needs to be included. Put it in the appendices and copy the relevant part of it into the main body of the report.

2. If the diagram, table, graphic or code fragment is not directly referred to from within the immediate text then it is not required. Put it in the appendices.

As a general rule, you should include the following in the appendices:

your original approved project proposal all evidence of your project planning and management

- the work breakdown structure for your project- the project scheduling documentation- any minutes of meetings with your supervisor

You should not include:

vendor and sales leaflets and brochures any photocopied material e.g. photocopies of publications and newspaper articles, etc. any scanned images without permission to copy any additional material in original format

Remember that all the pages in the appendices form part of the project and therefore must consist of printed pages that are properly paginated. It is therefore not possible to include other forms of material. Where necessary, the information provided in such material should be summarised and presented with comments. If it is essential to the project to show material in its original format then this should be submitted as a physically separate annexe to the project report.

4.13 Glossary (list of terms ...)A glossary may be required where there exists various levels of technical awareness amongst the expected readership, or in cases where a term’s usage in a computing context differs from that found in normal English. As a general rule, if you think that the term is one that a reader is unlikely to be familiar with then you should explain the term at the point where it is introduced, and then optionally list it with its definition in a glossary.

e.g. 'surfing'



5. SummaryWriting up a project of between 150 and 200 hours duration is far from being a trivial task. It takes planning and organisation and needs careful time management if the final copy is to meet the submission deadline. Start planning the report structure as early as possible and try writing draft chapters for the introduction and the literature review as soon as you can. Show these to your supervisor and get some early feedback on structure, content and most importantly, writing style and use of English.

You must include all the required report elements described in these notes. Other elements are optional and you must decide whether they add to your report or not. Your report should be more than just description. You should reflect critically on various aspects of the your work and the works of others that you have read about. Start positively with a relevant well-composed Abstract, and a good Introduction and finish strongly with firm conclusions drawn directly from your work and the critical observations that you can make about it. A good beginning and a good end might just make up for a weak or stodgy middle part!


Education

Comp 1181-project report structure