Resubmission Assessment Title: Resubmission assignment
Unit Level: 6 Reassessment Number: 1 of 1
Credit Value of Unit: 20 Date Issued: 04/07/2024
Unit Leader: Paul De Vrieze Submission Due Date: 01/08/2024 Time: 12:30 PM
Other Marker(s): N/A Submission Location: Other
Quality Assessor (QA): Gernot Liebchen Feedback Method: Brightspace
This is an individual assignment which carries 50% of the final unit mark.
REASSESSMENT TASK
Resubmission specifics
In the resubmission students are expected to continue work from the submission stage. However, instead of starting from
nothing, students will contribute further functionality to the system. Existing project items are open for contribution,
students can request to take over existing modules for extension (be assigned as lead), or to start a new (potentially
competing) module. Students should also look at further features to extend the existing scenario if there are insufficient
open items. Reworking existing modules should be limited to where the rework is intended to lead to some improvement
General task description
In the unit students will be working as if they are part of a larger software team developing parts of integrated enterprise
applications that support a ficticious business (a business that makes and sells some product - for this assignment
shoes). This is supported through the use of a github team where students will engage in various aspects of the software
development process that require them to collaborate, but also perform individual work. The work performed will form a
portfolio where individual contributions are assessed.
The overall project includes the following elements that students can contribute to (at least):
Overall architecture/landscape and choice of the technologies
Shared services/middleware
Project tooling (for example easy to use development environments/test environments)
Module development (actual modules of business functionality)
Code reviews
Bug reports/issues
Project planning/management (on github)
Pull requests (contributions to modules).
A key aspect is that each student must at least take ownership of a single module. This will become a repository they
manage that represents a unit of functionality that can be independently deployed (e.g. a docker container with a
microservice). For larger modules, the ownership of a module may be shared among a group of students (maximum 4),
but individual contributions must be clear. Other students can still contribute through issues and pull requests.
Unlike in a real project, it is permitted that modules overlap or compete in functionality. In such case however the
modules must have some significant difference (not merely in used programming language).
The project
The project is to provide the IT infrastructure that supports the manufacturing and sales business. There is scope for
student contributions to the direction this takes and how features and capabilities are prioritised. The resubmission is
intended to continue the multi-year evolving project.
As part of the project different modules of functionality need to be implemented. A module is represented through a
github repository. You must use the team issue tracker to request the repository. Modules can be managed ("owned") by a
single student or a team of up to 4 students. This does not mean that other students couldn't contribute through pull
requests. Students are marked on their individual contributions.
Page 1 of 6
APPROVED_L6_COMP6008_2023-24_resub_brief_(CWK1) Jul 2024 - v3
In addition to modules the project requires overall designs etc. Those are discussed and provided through a central
repository. There is a project management tool available through this repository. It is intended for overall project
coordination and project planning is recorded.
Requirements for student modules
There are some restrictions as to what makes a "valid" student module (as opposed to overall modules/repositories not
managed by students). This allows modules to work together in the overall project
Modules are represented by separate github repositories.
The modules must fit within the broader context of the project, and should be represented on the project
plan/overview (contributing to the plan/overview will allow this).
There must be an automated system for building the module into an appropriate artefact such as:
A docker container (at least targeting x86_64 Linux)
A library
A test report (aka. automated testing)
Modules may provide functionality to the "business", but may also support the project as such.
There is no requirement for any specific programming language to be used for any specific module
It is valid and expected to use code from other sources (other modules - e.g. shared build systems, and open
source projects) as long as this permitted by the appropriate license AND is acknowledged as such. Consider what
you would do in a professional context.
Where relevant, modules should provide automated testing
Tool modules must be beneficial to other modules in the project
Functionality modules must interact with other modules in the project, and may be designed interact with external
APIs
Modules must be secure and consider GDPR implications (where appropriate)
Module artefacts (such as docker files) must be provided through the github artefact repository for the
organization.
Expected portfolio contributions
Students are expected to contribute in various ways. Not all students are expected to contribute equally in each way, and
students are required to select their portfolio contributions from among their overall contributions (maximums are portfolio
maxima, not maxima on contributions made).
Up to 5 links to issues (bugs/feature requests) you reported against student modules (not overall project requests)
that are not self-reports (work the student will perform themselves)
Up to 5 links to issues where you are responding to a bug/feature request reported by someone else. You should
show your interaction with the reporter to address the issue
Contribution to the overall project
Up to 3 proposals for cross-module considerations (this could take the shape of discussions, pull requests or other
contributions). Note that it is permitted/expected that after the initial proposal the final result is the product of effort
from multiple people. Any individually identifiable contributions are acceptable.
Lead contribution (max 4 students per module) to between 1 (larger/more leads) and 3 (smaller/single lead)
modules. This is mainly about the code you contribute to the repository.
Up to 5 project work items (not tests - from the project planning system for the overall project) completed.
Up to 5 project test items (from the overall project planning system) completed.
Between 2 and 5 actions (links to evidence) of contribution/consideration of security and GDPR aspects of the
project
Any other items for special consideration
While a minimum level of contribution is expected, contributions are marked on quality and breadth of contribution
(demonstrating different skills/abilities), not quantity.
Note that due to the new nature of the assignment the numeric maximum in the portfolio highlight categories may be
adjusted to allow students to best show-case their work. This will be communicated through Brightspace in a timely
fashion.
ORIGINALITY REQUIREMENT
The following originality requirements will apply to this assignment:
You are allowed to use any Generative AI or other AI powered tools, such as ChatGPT, for specific aspects as directed by
the Unit Leader. Where any part of your assessment is sourced, or partially sourced from a generative AI tool, this
requires a reference in the BU Harvard style.
RESUBMISSION FORMAT
Page 2 of 6
APPROVED_L6_COMP6008_2023-24_resub_brief_(CWK1) Jul 2024 - v3
The contributions to the assignment must be done in the unit specific github team (to which students will be given access).
In addition, students are required to provide their portfolio as a document to be submitted on Brightspace. The portfolio will
mainly consist of (CLICKABLE) links to relevant github artefacts, a template will be provided separately.
MARKING CRITERIA
The following criteria will be used to assess the assignment:
The submitted portfolios will be assessed based upon the following assessment criteria and weights. Where the amount of
contributions is significantly below that of the group the marks will be reduced overall. If a category has insufficient
evidence a mark of 0 will be awarded for that group.
Note: Marking is done in line with the university Generic Marking Criteria. The 3rd and 1st class descriptions are
indicative but not exhaustive applications of these criteria in terms of the specific categories.
Page 3 of 6
APPROVED_L6_COMP6008_2023-24_resub_brief_(CWK1) Jul 2024 - v3
Category Marks Description Indicative 3rd class Indicative 1st class
Limited amount of
Overall contribution to the Insightful, significant
contributions that don't
Overall project overall project in elements that contributions that are
contribute much to the
contribution / 15 are not in the other categories. insightful and to the point.
overall project execution.
citizenship This includes helping others Likely these contributions are
Not particularly insightful
with issues. take over by others
and often perfunctory.
Actual contribution in terms of programming/coding. This may include scripting and other
Code contribution
code-light activities (configuring/setting up build systems)
Clear code that is easy to
Code that may be buggy, maintain, hard to misuse, and
The overall quality of the
Quality 15 hard to maintain, inefficient efficient. It is developed in
contributions
and overly complex consideration of the further
project (with communication)
Code that solves simple,
straight-forward problems. Code that solves challenging
The technical challenge of the Often can be directly problems in novel ways.
Difficulty 15
contributions acquired from external There are no ready-made
sources with no/minimal solutions present
modification
Small changes that have
The impact of the contribution inlimited scope of impact, but Code that has significant
the overall project. Note that are still worthwhile for the impact beyond a single
this would ignore competing module to which they are module. There is a good level
Significance 15
modules where they are applied. Some contributions of interaction in the
developed as simultaneous may be out of scope to the design/requirements of the
alternatives. unit (eg. extensive usability contribution
work).
The overall understanding/ability of security & GDPR aspects of development. This
Security/GDPR
includes both identifying and solving issues.
Limited security awareness,
misconceptions present.
The quality of the security Well-aware of principles, and
Limited appreciation of
measures evidenced throughout the
Quality 10 privacy (GDPR) aspects to
implemented/proposed and portfolio. Privacy is central in
the design, or
security feedback given the work (where relevant)
misapplication of the
principles.
Contributions are limited, The aspects may be
The impact of the security/gdpr perhaps only identifying challenging, novel
Significance 10
contributions. simple issues rather than approaches to solutions are
contributing to solutions proposed.
Non-code specific Contributions that are not directly code, but still contribute to the project and wouldn't class
contributions as citizenship. This includes designs, testing, etc.
Straightforward Insightful contributions that
contributions that improve the overall project
demonstrated limited skills. quality (eg. integration fuzz-
Quality 10 How good are the contributions
(eg. testing basic testing; Insightful issue
functionality; Limited issues reporting and contribution to
that are incomplete) other modules)
The impact of contributions
The contribution has
has marginal impact on the
How impactful are the significant impact on a
Significance 10 overall project, and is
contributions module, or even the whole
limited even within its
project.
module.
Page 4 of 6
APPROVED_L6_COMP6008_2023-24_resub_brief_(CWK1) Jul 2024 - v3
INTENDED LEARNING OUTCOMES (ILOs)
This unit assesses your ability to:
1. Evaluate architectural models relevant to the development of enterprise applications.
2. Select and apply programming design patterns relevant to a particular application.
3. Elucidate and evaluate factors relevant to the security of enterprise applications.
4. Elucidate and evaluate factors relevant to interoperability in enterprise applications.
5. Evaluate software tools used to support the development of enterprise applications.
QUESTIONS ABOUT THE BRIEF
Questions should be asked through the github team discussion forum
Requests in relation to the development project should be submitted as issues through github.
Individual questions should be addressed by email.
Students are advised that response times in the resubmission period may be reduced. File requests early with sufficient
clarity.
Unit Leader Signature Paul De Vrieze
Page 5 of 6
APPROVED_L6_COMP6008_2023-24_resub_brief_(CWK1) Jul 2024 - v3
(cid:72)(cid:101)(cid:108)(cid:112)(cid:32)(cid:97)(cid:110)(cid:100)(cid:32)(cid:83)(cid:117)(cid:112)(cid:112)(cid:111)(cid:114)(cid:116)
(cid:85)(cid:110)(cid:100)(cid:101)(cid:114)(cid:103)(cid:114)(cid:97)(cid:100)(cid:117)(cid:97)(cid:116)(cid:101)(cid:32)(cid:67)(cid:111)(cid:117)(cid:114)(cid:115)(cid:101)(cid:119)(cid:111)(cid:114)(cid:107)(cid:32)(cid:82)(cid:101)(cid:97)(cid:115)(cid:115)(cid:101)(cid:115)(cid:115)(cid:109)(cid:101)(cid:110)(cid:116)(cid:115)
If a piece of coursework is not submitted by the required deadline, the following will apply:
Failure to submit/complete any other types of coursework (which includes resubmission coursework without exceptional
circumstances) by the required deadline will result in a mark of zero (0%) being awarded.
The Standard Assessment Regulations can be found on Brightspace or via
https://www1.bournemouth.ac.uk/students/help-advice/important-information (under Assessment).
Exceptional Circumstances
If you have any valid exceptional circumstances which mean that you cannot meet an assignment submission deadline and you
wish to request an extension, you will need to complete and submit the online Exceptional Circumstances Form together with
appropriate supporting evidence (e.g. GP note) normally before the coursework deadline. Further details on the procedure and
links to the exceptional circumstances forms can be found on Brightspace or via
https://www1.bournemouth.ac.uk/students/help-advice/looking-support/exceptional-circumstances. Please make sure that you read
these documents carefully before submitting anything for consideration. For further guidance on exceptional circumstances please
contact your Programme Leader.
Referencing
You must acknowledge your source every time you refer to others' work, using the BU Harvard Referencing system (Author Date
Method). Failure to do so amounts to plagiarism which is against University regulations. Please refer to
https://libguides.bournemouth.ac.uk/bu-referencing-harvard-style for the University's guide to citation in the Harvard style. Also be
aware of Self-plagiarism, this primarily occurs when a student submits a piece of work to fulfill the assessment requirement for a
particular unit and all or part of the content has been previously submitted by that student for formal assessment on the same/a
different unit. Further information on academic offences can be found on Brightspace and from
https://www1.bournemouth.ac.uk/discover/library/using-library/how-guides/how-avoid-academic-offences
Additional Learning Support
Students with Additional Learning Needs may contact the Additional Learning Support Team. Details can be found here:
https://www1.bournemouth.ac.uk/als
Primary Research (Undergraduate Levels)
You should not be conducting any primary research (i.e. carrying out an investigation to acquire data first-hand, for example, where
it involves approaching participants to ask questions or to participate in surveys, questionnaires, interviews, observations, focus
groups, etc.) unless otherwise specified in the brief. However, if there is a genuine requirement to collect primary research data you
will require ethical approval before doing so. In the first instance, please discuss with the Unit Leader. The collection of primary data
without appropriate ethical approval is a serious breach of Bournemouth University's Research Ethics Code of Practice and will be
treated as Research Misconduct.
IT Support
If you have any problems submitting your assessment please contact the IT Service Desk - +44 (0)1202 965515 - immediately and
before the deadline.
Disclaimer
The information provided in this assignment brief is correct at time of publication. In the unlikely event that any changes are deemed
necessary, they will be communicated clearly via e-mail and Brightspace and a new version of this assignment brief will be
circulated.