IFB399Artefact Guide

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 2

DownloadIFB399Artefact Guide
Open PDF In BrowserView PDF
IFB399 – Capstone Project
Assessment 2 – Project Artefact
Submission Date:
Weighting:
Task:
Format:

Monday, October 29, 2018 (Monday, Week 14)
50%
Group with Individual Components
Zip Archive

Note that in the ordinary course of events, all members of the group will receive the same mark for
the Project Artefact assessment. The Group with Individual Components Task allows us to award lower
marks to one or more members of the group should there be clear evidence of wild variations in
contribution.

Introduction
This document provides an overall guide to artefact submission at the end of IFB399, the second of
the Capstone Units. This Project Artefact submission differs from IFB398 in that the Final Report and
the Project Artefact are here treated as separate assessment items. The IFB399 Final Report –
described elsewhere in the assessment section of BlackBoard – is intended as a guide to your project
for the benefit of the teaching team. The Final Report demands a number of sections that are about
the project context and goals, the project success and about tracking of your work against your plans.
None of those are relevant here.
However, you are also required as part of that Final Report to produce a summary of your artefact,
and this is essentially a summary of the evidence that you will submit here. We will mark this
separately on its quality as a report, but we will also use it to help us understand what you have
achieved.
It should be understood at this stage that it will be a good deal more difficult to achieve a mark at
grade of 6 or 7 standard for the Project Artefact than it was for the comparable assessment in IFB398.
At the end of the first semester, it was important to see that everyone was progressing and to assess
your work as a foundation for something more substantial. At that point, many teams had
encountered some significant delays in dealing with clients or getting their project on track.
Sometimes these were at least in part the fault of the team, and this was reflected in the marking. But
in some other cases, teams were given some leeway due to a late start.
By now we expect that everyone is in a position to do something at a reasonable level. We will be
understanding of delays genuinely beyond your control, but in general there is a strong expectation
that you will deliver.

Assessment
The overall approach will be as discussed in the initial class emails about these assessment items:
•
•

The Final Project Report includes a summary of the artefact – including a summary of the
validation and review undertaken, and the technical challenges encountered.
The Final Project Report must also include a user guide (development projects) or equivalents
such as an executive summary (consulting reports) and suitable alternatives for other project
types.

•

The Project Artefact submission will vary according to the type of project, but will essentially
be a zip of everything that you as a team think is relevant. This may include any code, unit
tests, acceptance tests, source documents, standards consulted, research papers perused,
design sketches and mock-ups, and so on… There could be many alternatives, and there is
likely to be a lot of material, so the artefact description in the Final Report will help us.

The assessment will be organised as follows:
•
•

•

•

There will be an overall CRA which will cover all of the possible project types, with a focus on
the deliverable actually produced by the team, and on its quality and presentation.
It will be especially important that the scope of the project aligns with what was agreed with
the client, and this will be the main focus of your discussion and agreement with your tutor.
In the CRA we will refer to this as Scope Delivered.
We will provide a series of specific guides for each of the projects, indicating the types of
factors to be considered in these assessments. In particular, the assessment of quality and
validation will vary across project types. The guides will be available by early in Week 5, and
these will match the project types considered in the Interim Report of IFB398 and in the Final
Report for this unit: the Software Project, the Technical Exploration and Design Projects, and
the Business Analysis or Consulting Projects. If you feel that your project is not a good fit for
one of these standard project types, then please raise this with us at IT Capstone
it.capstone@qut.edu.au, and then with your tutor at the week 6 meeting.
Your tutor will lead a discussion with you as a team to make these factors concrete in the
context of your specific project, and these will be agreed in draft form by the end of week 6
and signed off at the week 8 tutor meeting.

The overall CRA is available in the same link on BlackBoard as this document. The additional guides
will be added later at the same link. More guidance on the submission formats will be provided when
the submission link is released in week 12 or early in week13.

Interpretation, Project Difficulty, and Generosity of Marking
It is important to add an explanatory note about the role of the agreement that you will make with
your tutor. The idea is to provide clearly identified markers of the success of the project, which if done
well, will enable us to place your team at a particular grade level, although not necessarily right at the
top of the indicated mark range.
This will become clearer as you read the guides, but if, for example, we were to say that the
achievement of a particular level of functionality would be sufficient for a mark in the 6 band for Scope
Delivered, then there is an expectation that this functionality is delivered well. This is, one hopes, an
obvious point, but it is one worth making. In particular, we may record a mark in a lower band if the
features don’t work properly. Finally, we will be taking account of the difficulty of the project in the
agreement with the tutor, and in our expectations when it is delivered, and we may be more forgiving
of minor deficiencies in a technically challenging project than in one which should be straightforward
for students at this level. However, this will be within the constraints agreed with the tutor in week 8.



Source Exif Data:
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : Yes
Author                          : Holly Hutson
Comments                        : 
Company                         : 
Create Date                     : 2018:08:22 22:19:56+10:00
Modify Date                     : 2018:08:22 22:19:58+10:00
Source Modified                 : D:20180822121949
Subject                         : 
Language                        : EN-AU
Tagged PDF                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.4-c005 78.147326, 2012/08/23-13:03:03
Metadata Date                   : 2018:08:22 22:19:58+10:00
Creator Tool                    : Acrobat PDFMaker 11 for Word
Document ID                     : uuid:eb0a2d54-d386-4f08-a0d0-536f5b7fb4bb
Instance ID                     : uuid:d9ea48da-8273-4868-b27b-c0094bbaa3c4
Format                          : application/pdf
Title                           : 
Description                     : 
Creator                         : Holly Hutson
Producer                        : Adobe PDF Library 11.0
Keywords                        : 
Page Layout                     : OneColumn
Page Count                      : 2
EXIF Metadata provided by EXIF.tools

Navigation menu