Succeed UGprojects

Undergraduate Projects
How to Succeed
the University of Greenwich

What is a Project?
• A software development project
• where you are the consultant
• Doing work on behalf of a (virtual) client
• short timescale
• low budget
• Deliverables
• product
• report
• presentation
the University of Greenwich 2

Rules of the Game

• Clearly stated in the project handbook
• Make sure that you know the rules of the game
"Learn the rules well so that you know how to break

them properly"
Dalai Lama
• Think about how you are going to be assessed

• what are your assessors looking for?
• make sure that your assessor can tick all of the boxes
© 2007 the University of Greenwich 3

What are we looking for?

• Discovery of information
• read, research, investigate, gather
• Application of what you have learned
• to do something useful
• using the skills that you have learned over the past 2½ years
• plus some new tricks you self teach for the project
• Professional approach
• applying all those personal and professional skills
• Documentation of your achievements
• documentation is an important part of software
• your (virtual) client has paid you lots of money to do this project for them
• you need to convince them that you did a good job
• you need to be assessed
• you need to convince your assessors that you did good
• Demonstration of insight
• show awareness of your strengths and weaknesses
• your project's strengths and weaknesses
• reflective practice
• avoid metacognitive miscalibration
Report Sections
• Preamble
• title, abstract, contents
• Beginning
• approx 25%
• Middle Word count
• approx 55%
• End
• approx 20%
• Bibliography
• only include references which are cited in the report
• strict Harvard formatting
• Appendices
• lengthy technical material, test results, user guide, etc.

Beginning
• Introduction
• aims, justification
• why are you doing this project?
• Research
• discovering information
• your approach to finding information
• credible sources
• documenting your discoveries
• discussion of your source material
• clear referencing
• conclusions
• summary of what you have discovered

Referenced Material
• You must show that you have discovered information by reading
books, papers, articles, etc.
• written by other people and published somewhere
• credible authors
• credible publications
• Your text must contain references (citations) to these sources
• either numeric [17], alphanumeric [KM07] or Harvard style (McManus, K.
2007)
• Text that is copied from your sources must be formatted in "full
quotation marks and italic font" and clearly identified [PXR94]
• copied text is good
• but not too much of it
• Borrowed material such as pictures, figures, tables etc., must be
similarly identified
• graphical content must not float
• it must have a title and be referenced in the body of the text
• ... as can be seen in Figure 3.7 the upper stage of the reactor is...

Middle
• Requirements specification
• Technology
• identify the technology you have chosen to use
• avoid regurgitating superficial technical material
• justify your decisions
• Methodology
• describe your chosen approach
• remember: this is a short timescale project and you are a team of one
• Design
• plan what you intend to implement
• schemas, architectures, UML, and so on
• Implementation
• describe what you have done
• Testing
• discuss your approach to testing
• provide evidence of testing
• test schedules
• include test results in an appendix
• a good test finds errors, a bad test finds none
• analyse/discuss your test results
End
• Reflection
• possibly the most important part of your report
• Critical evaluation of the three ‘P’s
• Process – the project
• what went well/wrong?
• would you do it differently next time?
• Product – the thing you made
• what is good/bad about it?
• would you do it differently next time?
• what is the next step in the development?
• Person - you
• how have you changed during the project?
• what skills did you bring?
• what skills did you develop?
• All projects are open to some criticism
• this should come from you
• as opposed to from your assessors
Bibliography
• The first thing I read
• after reading the abstract
• A list of the source material cited in the report
• should not include material that is not cited
• this may be included in a list of associated reading
• must be credible sources
• not Wikipedia, no DIY books, no dummies guides
• must be accurate
• must be correctly formatted
• If you have no credible sources then find some
• and find a way of including them

Appendices
• The word count of your report is limited
• if you exceed the word count push some content into an
appendix
• Appendices are good for...
• lengthy technical material
• boring detail that would not fit in the report body
• all that UML
• source code - if you really need to include it
• data sheets from third parties
• minutes of meetings
• installation / user guide for your product
• all those screen shots
• test results
• Appendices should not float
• they should be mentioned / described in the body of the report
• ...further discussion of this can be found in Appendix D
Your Supervisor
• Your supervisor is not there to advise you in how
to implement your project
• they do not need to be an expert in your chosen field
• other school staff can advise on technical matters
• if you ask nicely
• database surgery
• Your supervisor is your assessor
• your virtual client
• You must talk to your supervisor
• you need to be proactive in arranging meetings
• you should take an agenda to each meeting
• you must record the meeting - take minutes
• include evidence of these meetings in your report
Blogging
• Keep a record of everything that you do on your
project
• no matter how small
• It is very easy to forget important stuff when
preparing your report
• failed experiments can be as important as successful
ones
• Blogging is more than just an aide-mémoire
• the 21st century laboratory notebook
• blog text can be copied into your report
• incredibly helpful in reflecting

Summary
• Learn the rules of the game
• Choose a suitable project
• Contact supervisor
• Gather sources
• Blog
• Deliver
• Product
• Report
UNDERGRADUATE PROJECT MARKING SCHEME

Understanding of the Problem Domain

• Identified an area to research or investigate and a problem to be solved
• Demonstrated understanding of the problem domain
• Shown how project objectives were formed and project planning took place
• Discussed the research or investigation within the context of the project
• Critical evaluation (of the appropriateness) of the current thinking on the
research area
• Compared similar products and systems
• Selected suitable criteria for development of product and ideas
• Chosen appropriate tools for modelling and development
• Production of requirements specification/client brief of suitable complexity
• Identified any legal, social, ethical and professional issues that are relevant to
the project

Development of Product and Ideas

• Clear plan of how the hypothesis might be tested
• In-depth investigation of the context/literature/other relevant
products
• A reasoned thread going throughout the project
• Use of suitable data collection techniques
• Use of suitable analysis tools to evaluate data
• Demonstrated complexity in the design and implementation of
the product
• Discussed the development process
• Shown that a number of alternative approaches have been
considered
• Explained the reasons for selecting a particular solution
• Demonstrated changes in the project plan
• Resolution of relevant legal, social, ethical or professional
issues
Product Build and Evaluation

• Demonstrated technical ability in building the product
• Demonstrated the full scope of product developed
• Shown that the product has been tested and
evaluated appropriately
• Discussed the quality of the product in relation to
original objectives and criteria
• Demonstrated the usability and appropriateness of
the product for the problem domain
• Identified where and how improvement can be made

4. Conclusions and Critical

Review
• Demonstrated critical thinking in writing up the project
• Discussed lessons learnt whilst completing the project
• Identified any problems encountered and discussed how
they were tackled
• Identified mistakes made and lessons learnt
• Reflected on how the project plan changed during the
development
• Made suggestions as to how the work can be improved
• Identified how the project might be taken further or
expanded

Succeed UGprojects

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Succeed UGprojects

Uploaded by

Copyright:

Available Formats

Undergraduate Projects

the University of Greenwich

the University of Greenwich 2

Rules of the Game

"Learn the rules well so that you know how to break

• Think about how you are going to be assessed

© 2007 the University of Greenwich 3

What are we looking for?

© 2007 the University of Greenwich 5

© 2007 the University of Greenwich 6

© 2007 the University of Greenwich 7

© 2007 the University of Greenwich 10

© 2007 the University of Greenwich 13

UNDERGRADUATE PROJECT MARKING SCHEME

© 2007 the University of Greenwich 15

Understanding of the Problem Domain

© 2007 the University of Greenwich 16

Development of Product and Ideas

Product Build and Evaluation

© 2007 the University of Greenwich 18

4. Conclusions and Critical

© 2007 the University of Greenwich 19

You might also like