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_202**4_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_202**4_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_202**4_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_202**4_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_202**4_resub_brief_(CWK1) Jul 2024 - v3

(cid:72)(cid:101)(cid:108)(cid:112)(cid:**)(cid:97)(cid:110)(cid:100)(cid:**)(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:**)(cid:67)(cid:111)(cid:117)(cid:114)(cid:115)(cid:101)(cid:119)(cid:111)(cid:114)(cid:107)(cid:**)(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.

請加QQ：99515681  郵箱：99515681@qq.com   WX：codinghelp