1 / 20

Project Guidelines: A Better Way to Write Up CSC111H Projects

This comprehensive guide provides structured advice for writing up projects in CSC111H, including sections on introduction, design, implementation, team work, testing, and conclusion. It includes detailed marking guides, presentation tips, and writing style recommendations to ensure a well-organized and successful project report. With clear directives on preparing the title page, table of contents, and other key elements, this resource aims to streamline the process and enhance the quality of project submissions. Supported by examples and best practices, this guide serves as a valuable reference for students undertaking CSC111H projects.

Download Presentation

Project Guidelines: A Better Way to Write Up CSC111H Projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Problems... • References • Extending JFrame • Overwhelmed by project? • Don’t have clear idea of how it should work? • OO Design • Design and implementation are being done separately • More….?

  2. class Person { public int age; public Person( int a ) { age = a; } public void setAge( int a ) { age = a; } public static void main( String[] args ) { Person x = new Person( 5 ); Person y = x; x.setAge( 7 ); S.o.pln("x= " + x.age + " y= " + y.age); } }

  3. class SampleFrame extends JFrame { JLabel l = new JLabel(“Label 1”); JButton b = new JButton(“Button 1”); JPanel p = new JPanel(); public SampleFrame(String title) { super( title ); // or setTitle( title ); p.add( l ); p.add( b ); getContentPane().add( p ); setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); pack(); } public static void main( String[] args ) { SampleFrame f = new SampleFrame(“A Better Way”); f.setVisible(true); } } A better way...

  4. CSC111HWriting up your project - some guidelines Dennis Burford dburford@cs.uct.ac.za

  5. Sections of the Final Report 1. Introduction: Explain the background to the project and what the reader can expect. What were the requirements of the project? 2. Design: Class diagrams, user interface design and component hierarchy. 3. Implementation: Printout of your code, which is well commented – do not give any printouts of code which we gave you. 4. Team work: How you and your partner worked together - division of work. 5. Testing: Correctness: What test cases were used, what they were testing, and results. User Testing: What technique(s) did you use? How well did the users use the system? What were their problems? 6. Conclusion: Briefly summarise the main points of your report.

  6. Marking Guide (35%) Content 27% • Introduction 3% • Design 5% • Implementation 5% • Team work 3% • Testing 8% • Conclusion 3% Presentation 8% • Overall Readability 4% • Overall Organisation 4%

  7. Other Elements • Title page must include the following: • Title of the project • names and student numbers of both students • CSC111H Project 2002 • Table of contents: • All sections and sub-sections with relevant page numbers • Page numbers! • If there are parts of the project which you have not completed, list them in a “Further Work” section after the conclusion.

  8. Other Elements • Tables • List results (of tests etc) • Display a lot of info in an ordered way • Caption! • Figures (images, diagrams) • Neat and Consistent placement • Not too many • Caption!

  9. Introduction & Conclusion • Introduction • Prepare the reader for what is to follow • What the project is about & the background • Objectives of the project • Any limitations • How the report is organised (very brief outline of each section)

  10. Introduction & Conclusion • Conclusion • Summarise the main findings of the report • Don’t introduce new facts which are not in the report. • State how the objectives of the project were achieved • Reader should be able to have a good overview of the project by only reading the introduction and conclusion.

  11. Writing Style • Formal writing style is most appropriate style for report • Sentences should be complete, but not complicated. • Avoid slang (“We learnt a heck of a lot from the project”). • Avoid abbreviations (“It’s an app. for chatting across a network”). • Cut down on wordiness. Don’t try to pad words to make report look longer. • “It would appear to be the fact that …” • rather: “It appears that …”

  12. Being Objective • Statements made in a report must be based on objective facts and not on your own opinion. • Bad example: “We think the application is user friendly.” • Better example: “Four out of the six users said that they were able to use the program without asking for help”

  13. Being Objective • Do not jump to conclusions: explain how you reached a conclusion. • Use objective language: • Try not to persuade readers with emotive words. • Bad example: “We worked extremely hard, but ran out of time, so did not complete the testing”

  14. Presentation of Report • The physical appearance of the reportis important, since it often affects the reader’s perception of the quality of the work done. • Recommendations: • Start each section on a new page. • Number all pages. • Be consistent with section numbering & fonts. • Label and caption any diagrams or tables (e.g. Table 2: A summary of the user testing results).

  15. Draft Report • Opportunity to get feedback before final report • Complete following sections for the draft report: • Introduction: complete • Design: complete • Implementation: Parts of the code that you have implemented already, such as the GUI mockup. • Testing: Document planned test cases for your final program (remember to have normal, extreme and erroneous test cases). The actual test results of the final system can be completed for the final report.

  16. Draft Report • It should also include a title page, all the section headings (even if empty), contents page and page numbers. • Do it on computer: it will save you time. • Due on 15 April.

  17. Draft Report Draft Report 10% • Contents page (1%) • Introduction present (1%) • Design: Class diagram (1%) • Design: GUI design (and hierarchy) (1%) • Implementation: Code printout (1%) • Comments looking good (1%) • Testing: planned test cases (1%) • Title page & page no’s (1%) • All headings there (1%) • Report looking good (1%)

  18. Exercises • Should we use the active or passive voice in a report: “We programmed the Chat Client to connect to the Server” OR... “The Chat Client was programmed to connect to the Server” • Do you think this is suitable for a report? Give reasons:   “It took us two weeks to solve the problem because when we write a program and it does'nt run, we decides to go and write another program(almost six programs with different coding)”

  19. Exercise: Comment on the suitability of the language Conceptual Overview and High Level Design  Originally when we started we knew we had to use trees somewhere. So the first thing that came to mind was the Binary tree.  We wrote a AnimalNode class that inherits from the TreeNode class of the BinaryTree and we also wrote a AnimalTree class that inherits from the BinaryTree class. But later on we realized that we don’t actually need a BinaryTree because there is a lot of functions that is not going to be of use to us. Actually just one function is needed and it is the Insert function. We need to insert data into our AnimalNode and the data is strings. To enter strings we just need to use cin.getline and then the string is entered.

More Related