Honours Computing Project

1. Honours Computing Project

2. What’s an “Hons. Comp. Project” • Individual piece of substantial work • Individual BUT with supervision • Substantial is open to interpretation… • Single Hons. students expected to work 30+ hours a week exclusively on their projects (from Feb 2009) • Joint Hons. students expected to work 20+ hours a week

3. Am I bovvered? • You should: the project is very important for your final degree classification! • For Single Honours: • 50 credits for program+report • Worth over 29% of the total for your degree classification • For Joint Honours: • 30 credits for program+report • Worth over 17% of the total for your degree classification • In either case: • Your project deserves proper care & attention

4. Why this Project stuff? • to give you the opportunity to undertake a substantial programming project, and to draw together the many skills you have acquired in the previous three years; • to give you practice in writing good technical English by writing a report of the project undertaken; • to give you instruction in a field not, or perhaps only lightly, covered elsewhere in your courses; • to act as one part of the assessment of your degree

5. Who’s involved? (1) • Two parties during the project • Student • Supervisor • Two more parties marking the project • Your supervisor will NOT mark you! • Two members of staff will independently mark you (more on this later)

6. Who’s involved? (2) • It is your responsibility as a student • Attend meetings (more on this later) • Meet the various deadlines • Supervisor • Two more parties marking the project • Your supervisor will NOT mark you! • Two members of staff will independently mark your project (more on this later)

7. How to do a project (in 4 steps) • Read what other people have done • What are the problems in their proposals? • Show that you know about the area • Propose new/improved/extended solution • Explain why we need it & what’s new about it • Compare with other people’s work • (Ideally) Explain why/when yours is better • Implement, document and test proposal • Write up

8. What a typical project entails • Meet supervisor at least once a week • Develop AND document a substantial and individual program/system/IT solution • This might involve trying alternatives • Science also progresses with unsuccessful stories • Write a report about your project • More on this later… • Meet deadlines • Both formal and informal ones

9. How to attend a meeting • Attitude is very important: • Not just another appointment, but a valuable opportunity to talk to someone about your ideas • Keep notes (to avoid repeating things): • What you did since you last met • What problems you came across & solutions you thought about • What you plan to do next week • Warning: • When you least want to meet, that’s when a meeting is most important (see “pitfalls”)

10. How to program (1) • Not just programming from scratch but also • Integration of technologies • Connecting existing solutions • Extending functionalities • Use software engineering techniques • Report on process and product • Even if your programming fails (you never got the product) you can still tell a story

11. How to program (2) • Classify functionalities as essential/desirable • Work on the essential ones first! • GUIs are not always that important… • Have easy to achieve functionalities • “Low-hanging fruit” – this is good for motivation • Avoid being in a situation where you will only find out if it works at the very end • Document as you go along (see “marking” later on) • Very important: record your design decisions! • What you decided, what the alternatives were, and why you chose what you chose as you program/develop • It is very easy to forget these… (see “marking”)

12. How to read (1) • Project marked on how much student knows • To know, you need to read • Books (real ones), articles, newspapers • Web sites, on-line documentation, chat/forums • Caution: • Wikipedia is NOT enough!! • The Web is an entry point, not the only source • When reading a reference • 5 minutes to decide if it’s worth reading • Read intro & conclusions first • If really important, read the middle part • Read chapter/sections selectively

13. How to read (2) Where can you find stuff to read? • Google and Google Scholar • Wikipedia • Library (QML) online catalogue • Digital libraries • ACM DL (http://www.acm.org/dl) • CiteSeer (http://citeseer.ist.psu.edu/) • Scirus (http://www.scirus.com/) • IEEE (http://www2.computer.org/portal/web/csdl)

14. How to read (3) Algorithm to read Input: one reference R • ListOfRs  R • While true do • Read & summarise first element of ListOfRs • Get list of references NewRs from first element • Remove first element from ListOfRs • Add NewRs to ListOfRs

15. How to read (4) • Read with a question in mind: • What is this book/paper/web page saying? • Is it any good for my project? • Does it overlap with my ideas? • Summarise what you read and keep notes • This will save you having to re-read stuff • Chapter 2 (Related Work) based on what you read

16. How to write (1) • One learns to write by writing • So, write often! • Keep records and notes • Electronic (blog, Word document) • Paper (notepad, loose sheets in folder) • Notes and records help • No need to remember (this adds stress)

17. How to write (2) • Writing-up can be very stressful • Common mistake: leave it to the very end • Pitfall: writer’s block! • Very difficult to start from a blank page… • Writing notes along the way helps a lot: • Chapters can be “assembled” from notes • Notes become chapters (with time to clean up) • Get friends and family to proofread drafts • Show proofread versions to supervisor • If writing-up too late, supervisor’s comments may be superficial

18. How to write (3) Typical project report structure: • Introduction (what, why, how) • Related work (what others have done) • Proposed approach/architecture (conceptual) • Implementation (technologies) • Testing and evaluation (scalability, faults) • Conclusions, discussion and future work

19. Common pitfalls • Paralysing ambition • Your project will be so good, you don’t even know where to start it… • Paralysing jealousy • Sees classmates progressing; feels “left behind” • Sees other projects as “cool”; feels “uncool” • Paralysing inadequacy • I am not good enough for this, why bother? • Downwards spiral • Cannot solve a problem; everything stops

20. How will your project be marked? • Not by your supervisor • So, factor this in your report • Do not assume readers will know what you are talking about • Independently, by two markers • Fill out report • Deposit report with secretary • Meet to agree on a mark • If they do not agree, a mediator is called in • Check out form here

21. More stuff • Please read on-line Manual: http:// … /teaching/CS4526 [5] • A different experience: • Use your time wisely – you will need it! • You should be able to manage the deadlines you set for yourself, and exercise discipline. • Supervisors are there to help, but ultimately it is YOU who will do the work…

22. A word on plagiarism • Always acknowledge your sources: • Acknowledge contributions of others • Properly cite source - i.e. full URL or reference • Writing “I got this from the Web” isn’t enough! • If in doubt, ask your supervisor!

23. Final Tips • Keep backups • If you don’t, you only have yourself to blame • Daily, weekly and monthly • Especially if you are going to work from home • Bad things do happen (some horror stories) • Write often • Summarise what you read • Record design decisions • Show early drafts to people • Document as you go along • Manage your time wisely • Allow time to NOT work in your project

24. And finally… Good Luck!