COMP 208/214/215/2162017-18

Lecture 8Demonstrations 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 the initial 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

Demonstration• Will take place in week 11 (30 April - 4 May

2018)• Given to your project reviewer• Must be booked by Friday April 27th, 2018 (e-

mail agreement with reviewer, as usual)• You choose the location (e.g. a lab, an office, a

meeting room) - 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 15% of the mark.

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.

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 than 30 minutes– including questions, dialogue and discussion.

• Make sure you practice the demonstration.

Supporting Material• specification document (final version)• electronic copy of any slide used during the demonstration.• user manuals, for ALL different type of user, with complete

instructions on how to use the system.

• make the implemented system freely available. All teams whodeveloped an application with a web-interface should have theirsystem correctly installed and ``live'' either on Departmental(recommended) or external disk space.

• The main web-address of the application must be provided to thereviewer (for instance as part of the demonstration slides).

• For non web-interface applications submit a CD (or other type ofmemory support) including (a) a fully executable version of thesystem, (b) instructions on how to use the disk and (c) all relevantsource code.

• Mobile clients should be provided in a CD or easily downloadable.

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.

Demonstration Assessment• Failure to attend the demonstration meeting by ANY

member of a team will result in that person being awarded a 0% mark for this assessment component

• 80% of the mark will be described by the ticks in the table on the FIRST page of the feedback form and the reviewers comments

• Remaining 20% of the mark will be described by the Specific Assessment Features mentioned on the SECOND page of the DEMO ASSESSMENT FORM

Video Recordings• If you decide to make a video

describing your system share it with the module co-ordinator as a Google Drive link

• The co-ordinator will import the video onto the University web-space

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 2017 (end of week 12) through VITAL (appropriate assignment task will appear in due course)

• 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 available by following the Professional Issues link 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 Submission

• Every student must also submit an individual contribution.

• The deadline is the same: 12 noon on Friday 11 May 2017

• Submission through VITAL

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.

Summary• The demonstration and the portfolio are opportunities to

show and to write about what you have done

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

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

VITAL (Demo)• Final requirement document• Presentation slides• User Manuals

• Made available during the Demo

Software (Demo)