1 / 22

COMP 208/214/215/216 – Lecture 8

COMP 208/214/215/216 – Lecture 8. Demonstrations and Portfolios. Demonstration and Portfolio. The demonstration is a chance to show the system you have built: To show that you have implemented your design To show that you have met requirements To show any interesting or unusual features

bedford
Download Presentation

COMP 208/214/215/216 – Lecture 8

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. COMP 208/214/215/216 – Lecture 8 Demonstrations and Portfolios

  2. Demonstration and Portfolio • The demonstration is a chance to show the system you have built: • To show that you have implemented your design • To show that you have met requirements • To show any interesting or unusual features • The portfolio is the final deliverable • It collects together the intermediate deliverables • It adds some new items: • Final report, testing report, screen shots, & user manual.

  3. Demonstration • Will take place in week 11 (30 April – 4 May 2012) • Given to your project reviewer • Must be booked by Monday 16 April 2012 (e-mail to reviewer as usual) • You choose the location(e.g. a lab, my office) - make sure THE LOCATION IS AVAILABLE AT THE REQUIRED TIME (!) and that you write on the e-mail where it will be. • The demonstration is worth 20% of the group mark.

  4. What should you show? • Features of your system; • Data entry; data modification; queries and reports; different user views • Choose some suitable scenarios and work through them to give coherence • New member; typical query session, etc. • Some system internals • To demonstrate your familiarity with software • Any special features • Web access; security features; graphical presentation of statistics, etc.

  5. What shouldn’t you show? • There is no need to show everything • Updating one kind of record is much like another • One query is often much like another • Give the flavour, but don’t get boring • The demonstration should be timed to last no more than30 minutes • including questions, dialogue and discussion. • Make sure you practice the demonstration. • There is no need to submit any documents with this.

  6. Your Portfolio • The portfolio brings together all the project work • There are several items included, so you will need to work as a team to produce it • The portfolio must be submitted by 12 noon, Friday 11 May 2012 (end of week 12) to the school office • The portfolio counts 35 % of the group mark.

  7. Portfolio Contents • Essentially a record of all the project work • A project report • Maximum 10 pages • Requirements specification • What was presented at the requirements review, modified as necessary • Design Documentation • What was presented at the design review, modified as necessary • Test Documentation • Some sample screen shots of your application • To indicate the look and feel of your system • A user manual • This can be screenshots of the full online user manual.

  8. The Report Should Contain: • Details of the team members and a summary of their roles on the project • An overview of the application: • What it does, who is intended to use it; why they might want to use it. • A description of what was achieved on the project • An evaluation of the strengths and weaknesses of the project • Suggestions for future developments • A 1-page discussion of how your project related to the codes of practice and conduct issued by the British Computer Society • A bibliography of materials used on the project.

  9. Report: People and Roles • Who was on the project? • What did people do? • A matrix of major tasks and people indicating major and minor roles might be a good way to do this • How was the group organised? • Any particular responsibilities etc.

  10. Report: Application Overview • Application Domain • Expansion of the original mission statement • Types of User • Description of the user views - who will use the system and why • Typical Queries • Searches performed on the database • Typical Reports • Regular provision of structured information.

  11. Report: Achievements • What was actually produced • Database compared with design • Queries and reports compared with requirements • Any “extra” features; e.g. • Web interface • Graphical presentation of statistical information.

  12. Report: Evaluation • What are the good points of your system? • What are the weak points? • Things that didn’t work • Things you would do differently • Things missing from requirements • How well did the team function?

  13. Report: Future Developments • Things that might be done to extend the system; e.g. • Inclusion of other information • Additional functionality • Additional user views • Commercial exploitation.

  14. Report: Professional Issues • There are 17 items in the BCS Code of Conduct • Which items apply to your project? • Which items did you comply with? • Were they any items not complied with - and why?

  15. Report: Bibliography • It is always important to say what sources you used • Include technical sources and any application domain material • These must be cited in the correct form • A forthcoming lecture will discuss how to cite sources.

  16. Test Documentation • Strategy • Data used: size of test data; selection of test data; real or imaginary • System testing: do the functions provided work? • Acceptance testing: do the functions provided meet user requirements? • Results • Known errors • Requirements satisfied.

  17. Screen Shots • These are intended to show what the system looks like • Two or three should suffice for most systems; • e.g. Introductory screen, typical entry screen, typical report • No need to show every screen, query and report: • Just show ones which are different.

  18. User Manual • Should include (as appropriate): • Overview of software: what it does; who it is for • hardware requirements • how to install the software • how to run the software • how to use the software • how to quit • Write in terms appropriate to target user. • The user manual may be included online as part of your system • In this case, your Portfolio should have screen shots of the entire user manual.

  19. Individual Submission • Every student must also submit an individual contribution. The deadline is the same: 3 pm on Friday 11 May 2012 • This contains: • A statement of what you personally learnt on the project (1-2 pages) • Technical skills • Project management skills • Group working and interpersonal skills • Any other skills acquired. • A Peer Assessment Form • An assessment of the contributions of team members - including yourself.

  20. Moderation of Group Mark • The individual submissions for the team are used to moderate the group mark • Your statement of what you learnt is assessed individually • Peer assessments for the team are collated and additions/reductions are made according to peer perceived contribution.

  21. Summary • The demonstration and the portfolio are opportunities to show and to write about what you have done • Together, these are worth 55% of the overall mark. • Everyone must also submit an Individual submission, comprising: • An Individual Learning Statement & a Peer Group Assessment.

More Related