Home

I have created a website linked below that shows the upcoming fixtures of the Premier League. Users must predict a score for each game of that week. Once the games have been played in real life, the website shows the predicted score the user has inputted for each fixture for that week as well as the actual score. If the user has predicted a correct score they will be given 3 points(for example if a user predicted Crystal Palace to win 4-0 to Man United they would be given 3 points because the actual score was Crystal Palace 4-0 Man United). If the user has predicted the correct result but the wrong score they will be awarded 1 point(for example if the user predicted Crystal Palace 2-1 Man United and the actual score was Crystal Palace 4-0 Man United, they would get 1 point for predicting Crystal Palace to win but won’t be given the extra 2 points because they didn’t predict Crystal Palace 4-0 Man United). If the user has predicted the wrong score and the wrong result they will get 0 points(for example if they guessed the score to be Crystal Palace 1-2 Man United they would get 0 points because the score was incorrect and they predicted Man United to win when Crystal Palace won). There is a leaderboard that shows all users’ total points as well as how many correct scores they have predicted as well as how many results they have predicted correctly. The aim of the game is to correctly predict the scores of each Premier League fixture and reach the top of the leaderboard. Below is an explanation of the structure needed for a report. I want you to use the context of my website and define the problem that it is trying to solve and what any conclusions could be made from creating this website. I also want a detailed explanation of what I need to do to create an effective piece of writing in context to the website I have created and what is needed. I don’t want you to write all of the report completely but show me some paragraphs that could be used for each section of the report as well as what else needs to be wrote about in that section.
STRUCTURE OF THE REPORT-Title Page
-Abstract
-List of Contents
-Introduction – always Chapter 1
-Research and Planning – two or more chapters
-Practical Work – three or more chapters
-Evaluation – one or more chapters
-Conclusions and Recommendations – one chapter
-References
-Appendices
-a.Terms of Reference
-b.Other appendices.
Each of the above should begin on a separate page.
TITLE PAGEThis should be arranged as shown in Appendix 2, which appears as an appendix to this handbook. The title may have been changed from the working title in the Terms of Reference.
ABSTRACTThe purpose of an abstract is to provide the reader with the essentials of your report in a very condensed form. (In a published paper, it would provide a basis for the reader to decide whether to read it or not). This means it should briefly summarise the nature of the project, its context, what work was carried out and what the major findings or conclusions were. Key technologies or approaches used will normally be mentioned. The marking schemes explain exactly what should be in your abstract. It must be no more than one side in length. It relates to completed work – it should not talk about what you are planning to do or the structure of the report. Write it last!
LIST OF CONTENTSList the contents of the report by chapter and sub-section against page numbers. Include the appendices, which document the deliverables. You may additionally decide to include a list of figures by page number, a glossary and/or a table defining any special symbols used in the report.
INTRODUCTIONThe introduction provides a fuller overview of the work to be done than is given in the abstract and sets the scene for the detail provided in subsequent chapters. The introduction is normally written (or at least finalised) at the end of the project, and is written retrospectively, i.e. it says what you did, not what you are going to do. This section is quite straightforward, but ensure that you have all the elements listed in the marking scheme. It is quite common for students to lose a mark or two by missing something out.
RESEARCH AND PLANNINGThe research and planning section may consist of several chapters. The exact number will depend upon the nature of the work you are undertaking. Typically, this part of the report should provide the reader with information they will need to know in order to appreciate and understand the work you have done in the rest of the project. You should assume a computer literate reader but not a specialist in your particular topic.
The research and planning follow on from the background given in the introduction. The marking scheme asks for the following five areas to be covered:
Clear identification and analysis of the problem to be looked at, identifying the key technical or other problems to be solved. Necessary background material that goes beyond the scope of the introduction may be included.
A critical review of literature related to the topic; this will normally address some combination of the underlying principles of the problem area and possible approaches to solving the problem. The relevance of these ideas to the project should be clear.
Discussion of approaches appropriate for the solution of the problem.
A discussion and justification of the product requirements if a product will be built.
Explanation and justification of the tools and techniques to be used in the project work.
Note that while all these elements are suggested, they do not necessarily map on to five separate chapters of your report. For example, a discussion of approaches to solving the problem may fit naturally at the conclusion of your literature review. “Tools and techniques” here refer to what you use to build the product or conduct the investigation, while “approaches” is used to include higher-level issues such as an overall strategy or architecture, the choice of implementing one algorithm rather than another to carry out a task, a general type of solution, etc. You should arrange the material in chapters in whatever way that best suits your project. Some projects will not even require all five areas. Ensure that you include everything that is necessary for your project.
Your research and planning should include a discussion of the wider issues, and critically examine the methods that might be used in solving the problem and any constraints that apply. Beware of presenting a shallow treatment of the subject which might be obtained from standard texts. You are expected to support your argument by exploring academic literature which is seminal and up to date.
The background and problem description should describe the actual problem you are looking at and set it in context. You should tell the reader about the computing problem(s) to be investigated, the product to be built, etc. as relevant, building on the brief overview given in the introduction. Bring out features of the problem you would not expect the reader to know about. Do not state the obvious.
The literature review will be a very important component of the research. Your literature review may discuss the problem that you are trying to solve, the question that you are trying to answer, possible solutions, methods of investigation, etc. as appropriate to your needs. You need to find out the state of the art – what others have done in this area, what solutions have been proposed, what findings have been achieved, what products have been created to tackle the same problem, what tools/techniques/approaches have been proven to be useful. The purpose is to help you to analyse the problem and its context, learn from existing related work, and propose appropriate solutions for your own project. You need to look for important concepts and principles, possible techniques, methods, tools, structures and etc that you could use in your project.
Note that the marking scheme says that a ‘critical review’ is required. You should not simply be relaying information or paraphrasing the sources that you have found, but identifying principles, structuring ideas, discussing the relevance to your project, and making evaluative comments about what you have found. It is useful to end the literature review by summarising the key ideas that it has contributed to the project.
Another pitfall to avoid is attempting to write about too many areas. You may find that there is a great deal of relevant literature and many subjects to review. It is better to aim for depth in the areas that are absolutely necessary and relevant to your project. An opposite example is the review where many areas are tackled but nothing of significance is said about any of them, and perhaps only one source (or no sources!) is cited for each. In this case, assuming that the project topic is suitable, the student would have been better advised to take a narrower focus.
The length of literature review should be guided by the needs of the specific project, but they are typically 2500 – 3000 words. You should use respectable academic sources, such as refereed journals or conferences, or other reliable and authoritative sources of information.
Once you have described your problem and put it into context by carrying out the literature review, you are in a position to identify and justify the appropriate approach to take to solving the problem. You will need to explain your approach at an overview level and give your reasons for choosing this approach. We are looking for a high-level discussion here. You will go into the details of exactly what you did (e.g. how you built the product, set up experiments, chose your participants, ran your tests, etc.) in the practical work chapters.
If your practical work is to conduct an investigation into a research question / hypothesis, you should discuss the possible strategies for conducting research or investigations in your subject area. This could be quite different for projects in different subject areas, for example, forensics, networking or HCI. You may need to consider research methods – for example, are you using one of the many varieties of experimental design? are you carrying out your study in lab conditions, or in the field? will you be taking measurements of the performance of real equipment, or using a computer simulation? You should review the possible alternative approaches, and explain why your chosen strategy was preferable to others, or was the only possibility.
If you plan to build a product, you need to identify the requirements for the product and produce its specification. The actual specification of requirements is part of your product and is marked under the product component. The research and planning chapters include your discussion and justification of those requirements. Reasons for choosing particular requirements could relate to user needs, constraints on project scope, to the findings of your literature review, etc. – whatever is appropriate to your particular project. You should discuss the methods you used to establish the product requirements, e.g., requirements elicitation and modelling, interviews, examination of existing products. It is appropriate to comment on significant findings that affect the decisions and to include any artefacts produced and the outputs of your investigations in the product documentation. It is expected that your requirements specification covers both functional and non-functional requirements. It is expected that your requirements specification covers both functional and non-functional requirements.
You must also identify and justify the methods, tools, and techniques that you will use to conduct your investigation and/or build your product. Again, the decisions should be based on literature review and/or examination of related work. You should justify that the chosen tools and methods are appropriate for solving the problem and meeting the requirements, and explain the deliverables that you are going to produce.
You may find that you now have several possible approaches and technologies that could be used to solve the problem. If this is the case, you should provide a short analysis of the possibilities justifying your selected route if the factors influencing your choices are worth discussing. There is no point in going through a spurious decision process if there is no real decision to be made. Many students choose a programming language or database or other software tool because they are familiar with it. As long as the tool is suitable, your own familiarity with it is sufficient reason for using that technology, and it is sufficient to indicate briefly why it is appropriate. If your project requires the use of some very specialised software or programming language, it may be useful to describe its main features as well as justifying its use, and if the focus of your project is exploring a particular tool or tool features, you will of course need to discuss the features in some depth. It is also suggested to briefly discuss the alternatives if the chosen tools/techniques do not work as expected. For some projects, there will not be any realistic alternatives to the tools and techniques that you are using. This is not a problem as long as you can justify it.
PRACTICAL WORKThis is a description and discussion of the practical work you have carried out. You have defined how it is to be assessed in the Terms of Reference.
How to organise the practical work chapters varies between projects, depending to the nature of your practical work. If you have conducted an investigative work without the aid of a product, you should organise the contents into three chapters as Design, Investigation and Results. However, if your practical work is mainly the development of a product, it makes more sense that you organise the chapters in terms of the product development life cycle, i.e., Design, Implementation and Testing. Please choose from below the appropriate section to read considering the nature of your own project.
Projects focusing on the development of a product
Projects focusing on the investigative work
You should discuss the design, implementation, and testing of your product. There are sections on each of these below. If there were other activities involved in development, such as analysis modelling based on the requirements specification, or if your project involved other practical work such as an experiment using your product, you should also include these: say what you did and discuss any interesting decisions or problems. If your product does not fit this model – for example, a project whose product is an information strategy – this section should discuss the work needed to create that product.
The narrative should especially identify areas of the work that were particularly interesting or difficult. Assume that the readership of the report will be computer literate individuals who will appreciate the problems you have tackled.
Justify in detail the method(s) you chose to synthesise a solution to the problem. Discuss how your reading of the literature guided you in your work. You may wish to refer to supporting documentation in your discussion of the solution; these will be held in appendices to the report.
In general, there should be neither bookwork nor theoretical material here. You should tell the reader what you did, why you did it and how you did it. Unless you have developed a worthwhile product or solved a challenging problem there will be little for you to say (and few marks to gain).
Design
Good products, whether software or hardware, must be designed. It is not professional to hack out a solution! You must describe and provide a rationale for that design. The artefacts produced are models (and perhaps prototypes) that form part of your product. In the report you tell the reader about your design and discuss the design decisions. Throughout the design section you should justify your choices. Discuss the implications of making different design choices, and the reasons for the design that you have selected.
The design chapter(s) should give a top-level view of how your product meets its requirements. For a software product, a good starting point is to describe the architecture of the software. (If your product is not software, what corresponds to the software architecture?)For example, suppose you are going to produce a computer game that could be played across the web. This will involve some software concerned with the communications across the network, some software concerned with the specific game and some with aspects that could be common to many games. This suggests an architecture consisting of three subsystems. You may feel there are other possible designs. If so, discuss each and then tell the reader which you decided to follow, and why.
Once you have selected a top-level design you can start to look at the details of each product component. You will produce design models as required by the development approach that you are following, and you will need to discuss your design decisions. For example, if you are using an object-oriented approach, you will probably describe and justify the important classes in your system. Design patterns are an area of increasing popularity and usefulness. Investigate making use of some. Explain which you have used and why.
Make careful use of figures and diagrams when describing the design. Any diagrams are there to help the reader understand what you have done. They must form a minor part of the chapter. The full design documentation will be marked under the product marking part of the module.
Another aspect of the design, which you may wish to write about, is the user interface. There is no point in simply relating HCI theory here, and merely describing or giving pictures of your screen designs is also inadequate: what the reader wants to know is how you have applied the theory. Justify your design choices in terms of usability principles, and illustrate them with a few carefully selected screen dumps.
You may wish to discuss the design process that you followed. Theoretical descriptions of design processes are unlikely to be interesting here. How you applied the process and how it affected your product, might be.
Implementation
In an implementation chapter, you are describing and justifying how you implemented your product, which for a software product means at the code level.
Do not attempt to describe every detail. For a software product, do not include large sections of program code. Any code presented should be to illustrate important and interesting features. You might want to describe the data structures you elected to use, e.g. in Java a LinkedList or a Vector, and explain why you chose the one you did. If there were any interesting low-level algorithms, you should describe these. If you feel it is important to put a significant volume of program code into your report, put it in an appendix and reference the appendix. (The appendix usually contains examples of your code, but the place for your full code is in your OneDrive product folder.)
Writing about program code can sometimes cause a student problems. You should be able to find good examples of articles that discuss implementations on the web. Read them and learn from how they do it. For Java a good source of examples can be found at JavaWorld.com.
Pick out the key parts of your implementation and provide a rationale for them. During your attempts to implement your product, you may have had to face unforeseen problems. Explain how you overcame them. They may have caused you to modify the original design. Discuss the implications of those changes.
Testing
Testing is not part of evaluation. It is the last part of your development activities. It is about how you checked to make sure your product was a viable and robust piece of software.
A testing chapter of your report indicates the approach you have taken to verifying and validating your system. You should not merely list the tests performed. Rather, you should discuss how tests were selected, why they are sufficient, why a reader should believe that no important tests were omitted, and why the reader should believe that the system will really operate as desired.
You should explain your overall strategy for testing: black box and/or white box, top down and/or bottom up, kinds of test beds or test drivers used, sources of test data, test suites, coverage metrics, compile-time checks vs. run-time assertions, reasoning about your code, etc. You might want to use different techniques (or combinations of techniques) in different parts of the program. In each case, justify your decisions. It is not necessary to describe the techniques; the reader knows about them. Tell the reader what you used and why in the context of your product. If you carried out usability testing, explain your approach to this.
Explain what classes of errors you expect to find (and not to find!) with your strategy. Discuss what aspects of the design make it hard or easy to validate.
Summarise the testing that has been accomplished and what if any remains. Which modules have been tested, and how thoroughly? Indicate the degree of confidence in the code:what kinds of fault have been eliminated? What kinds might remain?Do not include large volumes of tables purporting to be a test log here. These should be in the product documentation.
You should discuss the design, investigation, and results of your investigative work.
Design
You should discuss the detailed design of your research or investigation. You need to distinguish between what you planned to do and what happened when you actually carried out the work.Think about all the decisions that you had to make as you planned the work, and explain why you chose the approaches that you took and rejected others.For example, if you planned to carry out a study of how people use menu structures on web pages, you probably made decisions such as: What software will I use? How many people will be involved?How will they be chosen? What alternative tasks will I give them? On what basis will I divide the people into groups and / or assign them to different tasks? What exactly will I measure, and how, and what equipment will I need? How will I analyse the resulting data? If you are comparing the performance of networks using different configurations, how will you set them up, what tests will you carry out, how will you measure the performance, what data will you use, how will you analyse it, etc? How will you follow any relevant ethical or safety guidelines? You should justify these decisions, showing that you considered alternative solutions carefully.
Investigation
You should also discuss the investigation process. This does not mean that you have to repeat what you have already said about the design of your investigation, but you should comment on what happened during the investigation, e.g. how you conducted the experiments, how you collected data, or anything new or interesting that occurred, and perhaps add details that arose from events.It’s possible that you had to adapt your approach in some way.If things when wrong, or in the event you took an approach different from the one you planned, then you can explain what happened, what you did about it, and why. (It isn’t expected that everything will go according to the design: how you deal with situations that arise can be a very interesting part of your report.) If you have produced deliverables, you can present and discuss these.Anything that would impede the flow of your chapter can be provided in the appendices or, if large, on your disk.
Results
The final part of is the presentation of your results.You may have quantitative or qualitative data, or even both. The best way of presenting your results will be determined by the type of data and the nature of your investigation but will usually involve summarising the data in some way.Data analysis is too large and varied a topic to discuss in detail here, and how you do it will be very dependent on the project that you are doing.You are likely to have found out about appropriate methods as part of your project.In some cases, it may be appropriate to present calculations, e.g. to demonstrate how performance figures are derived.If you are doing statistical analyses, it will be helpful include levels of significance with the results where applicable.The presentation of qualitative data may involve summarising it, identifying significant factors, including representative examples, discussing interesting cases or critical incidents in depth, the use of quotations and illustrations, or identifying significant categories of content from textual data and looking at how often they occur.For example, if you had been interviewing people about their use of information, you might identify categories related to the type of information, the method of access, etc.
It may be helpful to use diagrams, charts or tables to present the work or the results.These should come with enough explanation for the reader to make sense of what you are showing.
In general, raw data in the body of your report will be limited to small elements or examples that that you are discussing.Further data can go in your appendices or (if bulky) on your OneDrive folder, and you should tell the reader where to look for it. Identifiable personal data should never be included in any part of your submission. If you need to refer to individuals, you can mention ‘Participant A’ in your study, or in organisational settings it may be appropriate to refer to someone by their job title.
EVALUATIONYou should present two or three critical evaluations of your work, in separate sections or chapters.
DISCUSSION AND EVALUATION OF FINDINGSIf you have conducted an investigation into a research question or hypothesis, this is where you discuss the meaning of your results.What answers have you found to the question that you are investigating?You should explicitly relate your findings to the problem, question or hypothesis, and discuss how far you have answered that question or solved the problem, whether your results support or refute your hypotheses, etc.You may wish to compare your findings with those of other work that you have discussed in your literature review.The marking scheme asks you do discuss your confidence in your findings and how far they can be generalised. Are there factors that affect the reliability of your results or conclusions?If this is relevant to your project, are your results statistically significant?Would you expect similar studies to achieve the same results?Would you expect that people carrying out similar work in a different organisation would come to similar conclusions?Remember that it is often not possible to generalise from a single case, or from a small number of tests participants etc.
AN EVALUATION OF YOUR PRODUCTIf you have built a product, you should evaluate your product from a technical point of view.You need to identify the strengths and weaknesses of your product in meeting its requirements, and review the possible alternative technical approaches to its design and implementation.Beware of the ‘anecdotal’ evaluation – you are expected to take a critical view and justify your argument.You should try to give evidence to support your evaluation: this could include the result of testing and user trials, feedback from clients, etc.Do not be afraid to discuss weaknesses: your evaluation will be assessed by its validity, regardless of the quality of the product.If your product is not software, you will need to be particularly careful in planning how it will be evaluated.Be sure that enough time is allowed for gathering necessary evidence: it is essential that this is thought about early in the project.
AN EVALUATION OF THE PROJECT PROCESSEvery project report should have a session/chapter for the evaluation of the project process. This section is fully described in your marking scheme. The emphasis should be on the learning process and on how well you managed your project work. What have you learned, and what would you do differently in future? Achievement of relevant objectives should be assessed, so look at the objectives in your Terms of Reference and see which ones are relevant here and which are part of the product/findings evaluation. You can reflect on your project plan and suggest other plans that might have worked better. You may also be able to discuss legal, social, ethical, or professional issues that have arisen and comment on your handling of them.
CONCLUSIONS AND RECOMMENDATIONSAn effective set of conclusions should not introduce new material. Instead, it should briefly draw out, summarize, combine and reiterate the main points that have been made in the body of the project report and present opinions based on them. The conclusions section should include a summary of what has been achieved, and of the main results of the project. To some extent this will involve summarizing aspects of the evaluation.
The main conclusions will relate to the problem that you tackled: what answers and solutions did you find to your research question; what did you conclude about your hypotheses; what product did you build?You should also sum up what you achieved, and how far your aims and objectives were met.You may also have drawn other conclusions from the work, perhaps about the effectiveness of methods or tools used.
It is quite likely that by the end of your project you will not have achieved all that you planned at the start; and in any case, your ideas will have grown during the course of the project beyond what you could hope to do within the available time.The recommendations will focus on further work: this is where you describe your unrealized ideas.It is where you tell the reader what extra you wish you could have done to benefit this subject area.Try to look beyond the work that yourself have done to the subject context.A good set of recommendations can provide the basis for a future project.You may also have more general recommendations for other people working in this field.