240 likes | 372 Views
Honours Computing Project. 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)
E N D
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
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
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
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)
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)
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
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
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”)
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
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”)
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
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)
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
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
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)
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
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
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
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
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…
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!
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
And finally… Good Luck!