UK8906
**ADVANCED DEVELOPMENT (COMP6008) | Resubmission Assessment Brief**
**Unit Title:** ADVANCED DEVELOPMENT (COMP6008)
**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 scratch, 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 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 fictitious 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 cases, however, the modules must have some significant difference (not merely in the programming language used).
### 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 prioritized. 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.
In addition to modules, the project requires overall designs, etc. These 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:**
- 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 artifact 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 is permitted by the appropriate license AND is acknowledged as such.
- 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 to interact with external APIs.
- Modules must be secure and consider GDPR implications (where appropriate).
- Module artifacts (such as Docker files) must be provided through the GitHub artifact 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 showcase their work. This will be communicated through Brightspace in a timely fashion.
---
**ORIGINALITY REQUIREMENT:**
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:**
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 artifacts, a template will be provided separately.
---
**MARKING CRITERIA:**
The following criteria will be used to assess the assignment:
| Category | Marks | Description | Indicative 3rd class | Indicative 1st class |
|------------------------------------|-------|----------------------------------------------------------------------------------------------|--------------------------------------------|--------------------------------------------|
| **Overall contribution to the overall project / citizenship** | 15 | Insightful, significant contributions that are not in the other categories. | Limited amount of contributions | Insightful and significant contributions |
| **Code contribution** | | | | |
| - Quality | 15 | Clear, easy to maintain, and efficient code | Buggy, hard to maintain, and complex code | Clear, maintainable, and efficient code |
| - Difficulty | 15 | Solving challenging problems in novel ways | Simple, straightforward problems | Challenging problems solved innovatively |
| - Significance | 15 | Impact beyond a single module | Marginal impact | Significant impact |
| **Security/GDPR** | | | | |
| - Quality | 10 | Well-aware of principles and central privacy considerations | Limited awareness and misconceptions | Well-aware of principles and central privacy considerations |
| - Significance | 10 | Challenging, novel approaches to solutions | Limited contributions | Significant and novel approaches |
| **Non-code specific contributions** | | | | |
| - Quality | 10 | Insightful contributions that improve overall project quality | Limited skills demonstrated | Insightful and high-quality contributions |
| - Significance | 10 | Significant impact on the module or project | Marginal impact | Significant impact |
### 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