Faculty of Engineering, Environment and Computing 6002CEM Mobile App Development
Assignment Brief and Grading Rubric 2023
Module Title Mobile App Development
Ind/Group Individual
Cohort January
Module Code 6002CEM
Coursework Title
Designing and Building a Mobile App
Hand Out Date 24/01/22
Lecturer
Mr. Bogdan Boldur
Due Date 06/04/23 Online: 18:00:00
Estimated Time (hrs):
Word Limit*:
Coursework Type Individual Practical Element
75% of Module Mark
Submission Arrangement Online via Aula: A text file with links (Video Link + Github Repository + Use case diagram link) uploaded through the assignment link.
File Type:
A Word/PDF file with three links:
A 10-min maximum demonstration video uploaded to Google Drive/YouTube
A Coventry University GitHub Repository link where you hosted the project
A link or image of the use case diagram for your project
Mark and Feedback Method: Rubric marks and comments
Failing to submit the Coventry University GitHub Repository link will result in a zero mark for this assessment.
Module Learning Outcomes Assessed
1. Design and implement a mobile application, showing systematic knowledge of relevant tools, methods and processes.
2. Understand and critically evaluate the different tools and techniques for mobile application development.
3. Scope, design, implement and critically evaluate a basic security policy to keep confidential data safe on a mobile device.
4. Demonstrate an ability to maintain ease of data access/usability across several platforms.
Assignment Brief
You are required to design and build a .NET Maui app that demonstrates your proficiency in the skills that have been taught during the module. The application must be developed using the C# programming language and .NET Maui framework.
The app should preferably match the one you proposed in your first coursework, however, this is not mandatory, and you can change your idea if you feel that the one proposed does not align with your interests anymore.
You can use any kind of 3rd party libraries if they are not paid for or would in any shape or form generate the application for you (please consult with the module leader if in doubt).
You may use sample code from the labs, videos, demos or any other online sources referenced throughout this module if you understand why you used it and what it does. However, you must annotate the code if you copied bigger chunks and specify the reason for copy/pasting it. Copying code from other sources and not properly referencing it will be dealt with accordingly.
Submission file requirements (Can be submitted as Word or Pdf):
1. Video Link:
a. You are required to create a video that clearly showcases the application you have
developed. As part of this video, you should show each screen that you can navigate to within the application and any sensors/external APIs or cloud providers that you have used. Guidelines to follow can be found below:
i. If you use any external APIs or cloud providers for authentication services or data persistence, you must make sure that we can clearly see the setup you made (either explain in the video or have images with the dashboards/ code setup – in case of public API usage - in the submission file).
ii. The video must be no longer than 10 minutes and have a quality of at least 720HD.
iii. Show your app running on the screen and how to use it.
iv. The video link must be uploaded on OneDrive/YouTube and be provided in the submission file.
v. The video must have either VOICE or SUBTITLES so we can understand what you have done in case there might be any confusion.
2. GitHub Repository
a. As part of this submission, you need to create a repository in the 6002CEM
organization. Your individual repository should be named 6002CEM_StudentName
b. The repository must have a Readme file containing the name of the application and a brief summary (50-100 words) of what it is about.
3. Link/Image attached to the use case diagram:
a. The use case diagram can be designed in any software as long as it corresponds with
the requirements of use case diagrams.
1. You are expected to use the Coventry University APA style for referencing. For supportand advice on this students can contact Centre for Academic Writing (CAW).
2. Please notify your registry course support team and module leader for disability support.
3. Any student requiring an extension or deferral should follow the university
process asoutlined here.
4. The University cannot take responsibility for any coursework lost or corrupted on disks,laptops or personal computer. Students should therefore regularly back-up any work and are advised to save it on the University system.
5. If there are technical or performance issues that prevent students submitting courseworkthrough the online coursework submission system on the day of a coursework deadline, an appropriate extension to the coursework submission deadline will be agreed. This extension will normally be 24 hours or the next working day if the deadline falls on a Friday or over the weekendperiod. This will be communicated via your Module Leader.
6. Assignments that are more than 10% over the word limit will result in a deduction of 10%of the mark i.e. a mark of 60% will lead to a reduction of 6% to 54%. The word limit includes quotations, but excludes the bibliography, reference list and tables.
7. You are encouraged to check the originality of your work by using the draft Turnitin links on Aula.
8. Collusion between students (where sections of your work are similar to the work submitted by other students in this or previous module cohorts) is taken extremely seriously and will be reported to the academic conduct panel. This applies to both courseworks and exam answers.
9. A marked difference between your writing style, knowledge and skill level demonstrated in-class discussion, any test conditions and that demonstrated in a coursework assignment may result in you having to undertake a Viva Voce in order to prove the coursework assignment is entirely your own work.
10. If you make use of the services of a proof reader in your work you must keep your original version and make it available as a demonstration of your written efforts.
11. You must not submit work for assessment that you have already submitted (partially or in full), either for your current course or for another qualification of this university, with the exception of resits, where for the coursework, you may be asked to rework and improve a previous attempt. This requirement will be specifically detailed in your assignment brief or specific course or moduleinformation. Where earlier work by you is citable, i.e. it has already been published/submitted, you must reference it clearly. Identical pieces of work submitted concurrently may also be considered to be self- plagiarism.
This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third parties orposted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.
Marking scheme
No attempt (0.00)
App complexity (35%)
UI usage – Video bound (20%)
No UI observed.
No features observed.
One feature can be observed. *
Two-three features can be seen. *
Four features can be seen. *
Five features can be seen. *
More than five features are present. *
Very poor (20.00)
Very limited usage of UI (few UI elements and extremely basic).
Poor (40.00)
Limited usage of UI can be observed (Basic UI elements only).
Good (60.00)
Adequate usage of UI can be observed (Basic UI elements and few medium complexity elements).
Excellent (80.00)
Good usage of UI can be observed (Basic UI elements and medium complexity elements).
Outstanding (100.00)
Comprehensive usage of UI can be observed (Basic UI elements, medium UI elements and complex UI elements).
Number of features- Video bound (10%)
No UI styling/ element styles observed and no usage of app wide resource dictionaries.
No usage of Themes.
Most elements are not styled but some can be seen styled directly in their XAML page. No usage of app wide styles using resource dictionaries.
No usage of Themes.
Most elements are styled. They can be seen styled directly in their XAML page exclusively.
No usage of Themes.
Most elements are styled. There is a mix of UI elements defined using styles in Resource dictionaries and UI elements styled directly in their XAML page.
No usage of Themes.
All elements are styled. There is a mix of UI elements defined using styles in Resource dictionaries and UI elements styled directly in their XAML page.
No usage of Themes.
All UI elements are defined using styles in Resource dictionaries.
Clear usage of different themes (e.g., White/Dark theme).
No link provided or link provided that leads to an empty repository.
Link provided, valid repository (Readme included)
Less than 6 commits
Less than one week commit history
One branch
No merges present
Link provided, valid repository (Readme included)
At least 6 commits
At least one week commit history
One branch
No merges present
Link provided, valid repository (Readme included)
At least 10 commits spaced regularly during the development time
At least one week commit history
Two branches (one for releases, one for development)
At least one Merge from development back into release
Link provided, valid repository (Readme included)
At least 12 commits spaced regularly during the development time
Clear branch for releases and development
At least two weeks commit history
Attempted to use feature branches (one) for individual features.
One Merge from development back into release and one merge from a feature branch back in the development branch
Link provided, valid repository (Readme included)
At least 12 commits spaced regularly during the development time
Clear branch for releases and development
At least two weeks commit history
Attempted to use feature branches (At least two) for individual features.
At least two Merges from development back into release and at least two merge from a feature branch back in the development branch
No attempt at integration MVVM can be seen. All the business logic is in the code-behind.
Very limited attempt at integration of MVVM.
There is very limited attempt to use one view-model.
Most of the code still resides in code- behind.
Limited attempt at integration of MVVM.
At least one view-model has been implemented correctly in the app.
There is still a lot of code behind in the other pages of the app.
Adequate attempt at integration of MVVM.
Most view-models have been implemented correctly in the app.
There is still some code-behind left in some of the pages but overall, not worrying.
Good attempt at integration of MVVM.
Most view-models have been implemented correctly in the app.
There is a base view- model that all the others inherit from to improve readability and follow DRY principle.
There is very little code behind left across the app.
Comprehensive attempt at integration of MVVM.
All view-models have been implemented correctly in the app.
There is a base view- model that all the others inherit from to improve readability and follow DRY principle.
No code-behind (except where interaction with framework was absolutely necessary) can be found in the app.
Styling/Usage of resource dictionaries (5%)
Version control (10%)
App architecture (40%)
MVVM integration (20%)
Software design patterns
No software design pattern used.
One software design pattern used or at least attempted**.
One software design pattern correctly used**.
Two software design patterns used**.
Three software design patterns used**.
Four or more software design patterns used**.
used (10%)
Separation of concerns (10%)
No attempt to separate the concerns.
The whole application is residing under the root project.
No clear separation of concerns within the app.
Not all of Models/View- models/Services/Inter faces have their own folders but at least 1 of the above categories can be seen in the project structure.
Somewhat decent separation of concerns.
Not all of Models/View- models/Services/Interfac es have their own folders but at least 2 of the above categories can be seen in the project structure.
Adequate separation of concerns.
Not all of Models/View- models/Services/Inter faces have their own folders but at least 3 of the above categories can be seen in the project structure.
Good separation of concerns.
Not all of Models/View- models/Services/Interfac es have their own folders but at least 4 of the above categories can be seen in the project structure.
There might be other folders as well for different functions of the app such as Converters.
Clear separation of concerns.
All of Models/View- models/Services/Int erfaces have their own folders respectively.
There are other folders as well for different functions of the app such as Converters.
Use case diagram (15%)
No use case diagram,
Very poorly designed use case diagram, no use cases defined or wrongly defined, no actors, no proper boundary, no usage of or
Poor designed use case diagram, very limited use of use cases but at least two present, one actor present, boundary attempted, no use of and
Adequately designed use case diagram, decent number of use cases (at least three) at least one actor present, boundary well defined, attempted to use and
Adequately designed use case diagram, decent number of use cases (at least three) at least one actor present, boundary well defined, limited use of and (at least one relationship of or is present)
Comprehensive use case diagram, clear boundary, complex relationships between use cases, multiple actors, well defined boundary, clear usage of and relationships
Basic UI interface elements: e.g., Buttons, Images, Entries, Slider, StackLayout, Image, ContentPage, Label, Checkbox, RadioButton
Medium UI interface elements: e.g., ListViews, GridLayouts, Scrollviews, Frame, DatePicker, CollectionView, RefreshView
Complex UI interface elements: e.g. TabLayout, CarouselPage, SearchBar, TwoPaneView, Flyouts (usable), Maps, Custom renderers (for full native interop)
*A feature can be considered a page if it has working functionality present that is different from other pages.
**Does Not include the fact .NET Maui comes pre-loaded with IoC (Inversion of Control) and DI (Dependency Injection) if I cannot see a clear usage of these patterns.