COMP 208/214/215/2162019-20

Lecture 8Demonstrations,

Portfolios, and Individual Submissions

Rationale• 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 the initial requirements– To show any interesting or unusual features

• The portfolio is the final deliverable– It collects together some intermediate deliverables– It adds some new items:

• Final report, testing report, screen shots

Demonstrations

Demonstration (Updated Plan)• Two components:

– A video pitch of your system– A web chat with reviewer

• By Friday April 24th, 2020 submit 10 minute video demonstration of your system

• Between 27 April - 1 May 2020 have an on-line meeting with your reviewer to discuss the content of the video and any other issue related to your software

• The demonstration is worth 15% of the mark.

What should be in the video?• Features of your system;

– Data entry; data modification; queries and reports; different user views

(choose suitable use-cases and work through them)• Some system internals

– To demonstrate your familiarity with software• Any special features (as appropriate)

– Web access– graphical presentation of statistics– the working of interesting algorithms

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 video should last no more than 10 minutes

Supporting Material• The recorded video: uploaded to stream.liv.ac.uk, and link forwardedto the reviewer

• user manuals, for ALL different type of user, with completeinstructions on how to use the system.

• Access to the implemented system.– For systems with a web-interface, these should be correctly installed and ``live''either on Departmental (recommended) or external sites.

The main web-address of the application must be provided to thereviewer– For non web-interface applications teams should provide a link to a full version ofthe code and EASY TO FOLLOW, COMPLETE instructions on how to install and use thesystem

Supporting MaterialIn other words, submit through VITAL• user manuals, for ALL different type of user, with

complete instructions on how to use the system.• A pdf file containing– a link to the video demonstration, and– details about the implemented system (as specified in notes.pdf,or the previous slide)

Attendance and Ownership• The video might NOT show ALL members of a team,

but it is understood that, unless clearly andexplicitly stated in the video itself, ALL teammembers contributed to its production

• The web-meeting MUST be attended by all teammembers

• All submitted written documents MUST be signed by(or otherwise labelled with the names of) allparticipating members of the team.

Failure to comply with the above rules will result inmark deduction for the “missing” team members.

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 use/run/quit the software

• Write in terms appropriate to target user. If the system has several types of users there should be a different user manual for each of them!

• The user manual may be ALSO included online as part of your system– In this case, your Portfolio should have screen shot

samples of the entire user manual.

Portfolios

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 9am,

Monday 11 May 2020 through VITAL • The portfolio accounts for 30% of the module

mark.

Portfolio Contents• A project report

– Maximum 10 pages• 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

Meeting Notes• MEETING NOTES MUST NOT BE

INCLUDED IN THE PORTFOLIOHOWEVER (!)

• MAKE SURE ALL MEETINGAGENDA/MINUTES ARE READILYAVAILABLE IN YOUR GROUP VITAL“File Exchange” AREA.

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 wantto 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 BritishComputer Society

• A bibliography of materials used on the project.

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.

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.

Report: Achievements• What was actually produced

– Database compared with design– Queries and reports compared with

requirements– Any “extra” features IF PRESENT(!); e.g.

• Web interface• Graphical presentation of statistical information.

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?

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.

Professional Issues• Awareness of professional issues is considered

important for software developers.

• The British Computer Society issue a code of conduct.

• You should be aware of what this says, and follow it as applicable.

• It is also available by following the Professional Issueslink from the module homepage.

Report: Professional Issues• There is a number of 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?

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.

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.

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.

Portfolio Assessment• The report is worth 40% • Design documentation 30%• Test documentation 15%• Sample screen shots 15%

Individual Submissions

Individual Submission

• Every student must also submit an individual contribution.

• The deadline is the same: 9am on Monday 11th May 2020

• Submission through VITAL (but one submission for each member of a team)

Individual SubmissionThis contains:

• A statement of what you personally learnt on the project (max 1 page)

• 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.

Moderation of Group Mark• The individual submissions from each team

member are used to adjust the individual marks• Your statement of what you learnt is assessed

individually• Peer assessments for the team are collated and

additions/reductions against average team mark are made according to peer perceived contribution (typically within a 20% range).

Summary• The demonstration and the portfolio are opportunities to

show and to write about what you have done

• Together, these are worth 45% of the overall mark.

• Everyone is also required to provide anIndividual submission, comprising:– An Individual Learning Statement & – a Peer Group Assessment.