COMP2100/6442 Group Project | A better world, it’s in our hands!
v.01 - Project Description released (2024-03-25)
Assessment weight: This project is worth 30% of your overall mark.
Code due date: Thursday, Week 11 at 11h59 pm (last commit for the code)
Report (group and individual reflection) due date: Friday, Week 11 at 11h59 pm (last commit for the
report, Wattle for individual reflection)
Presentation slides due date: Friday, Week 11 at 11h59 pm (slides must be uploaded to Office365)
Group Presentation (Minute Madness): Monday, Week 12 (during lecture time)
No late submission allowed; No extensions.
Each group should consist of 5 students. Groups can contain a mix of undergraduate and master
students and students from different labs.
**Your group must be created and registered on Wattle, or alternatively, you can register for
`RandPool` on Wattle and you will be randomly assigned to a group by us.
Register your group and checkpoint by April 3rd (Wednesday) on Wattle. More information will be
released on the Ed Forum about the registrations.
Do not start late, it may impact your project outcomes.**

Android Studio: Please use API level 33 for your target and compile SDK. For Min. SDK, you may select
the default or an API level between 29 and 31. If you use another API Level, you must explicitly mention
it in your report to avoid losing marks.
Introduction
Key requirements for the App
Part 1: Basic App
Part 2: Custom features of the App
List of Custom Features
Search-related features
UI Design and Testing
Greater Data Usage, Handling and Sophistication
Firebase Integration
Peer to Peer Messaging
User Interactivity
Privacy
How many features should my group implement?
Voice your feature
Surprise!
Checkpoints
Project Submission
Report (Important!)
All attempted features MUST be documented
Other important items
Code development
Individual Reflection and Peer- and Self-evaluation
Group Presentation (Minute-Madness)
Examples and Frequently Asked Questions (FAQs)
What kind of app should we develop?
How should I develop the search mechanism?
What about the data?
What about the data structures?
Why and how to simulate a data stream?
What does `[stored in-memory]` mean?
Why and how to implement these features?
Which design pattern should I use?
How complicated should my grammar be?
Can I use the lab code?
Appendices
Assessment and General Policies
Late submission policy
Originality
Marking Criteria
Individual Contribution
Best Practices for Using Generative AI Tools for Software Construction
Assessment Rubrics
Other Information
Introduction
The objective of this project is to gain some experience in the process of software construction, through
designing and implementing a graphical user interface (GUI) application and using several important
development tools (particularly Android Studio and Git) with Java. Most importantly, it is an opportunity to
reason about and put into practice some fundamental software construction concepts.
As you complete this project, you should reflect on the overall design and the software engineering process
you used in completing it. Note that this is not an assignment about who could write the best app only, but
who could best manifest what they have learned in this course and during the implementation of this app.
The journey (as revealed in regular meetings, regular contributions/commits, etc.) is just as important
as the final app.
The topic of the project: A better world, it's in our hands!
You are tasked to develop an app and come up with your topic to address at least one of the following:
• one of the 17 Sustainable Development Goals (SDGs) by the United Nations; or
• one of the 17 targets in "Closing the gap” by the Council of Australian Governments.
While these are some overarching goals, you are encouraged to come up with your own ideas to
address them. (B creative!)

You shall first come up with your goals and a specific theme for the App, then implement a range of
features (functionalities/capabilities) and present them in the GUI. Your software, of course, needs to be
of good quality, sufficiently tested, and utilise the concepts taught on our course.
Although the content for your App is open, your implementation must meet a range of requirements.

Note that we do not expect a fully operational app - simplifications can be made as long as the core
architecture is well-developed. The key assessment aspects include Data Structures,
Tokeniser/Parser, Data Persistence, Design Patterns, Software Testing, and Code Quality.

Note that the topic of this Group Assignment aligns with the McCusker Prize in Humanitarian
Engineering granted by ANU. You can read more about the prize here and submit your application in
the upcoming round.
This is not a requirement for the course. Your marks will not be affected whether you submit or not, win or not. It
is just a great opportunity that you are encouraged to pursue.
Key requirements for the App
Part 1: Basic App
In the first part of the assignment, you must create an app (with generated APK) that allows users to:
(i) login, (ii) visualise and (iii) search for information within the app.
Marks will be awarded for the following listed requirements. It is advised, although not necessary, that
you complete this basic application before proceeding to the custom features.
List of Basic Features, each with a [FeatureId]:
1. [LogIn] Users must be able to log in (not necessarily sign up). (easy)
Important: You must include the following two accounts for markers' access to your App:
Username: comp2100@anu.edu.au Password: comp2100
Username: comp6442@anu.edu.au Password: comp6442
2. [DataFiles] Create a dataset with at least 2,500 valid data instances, each representing a meaningful
piece of information in your app. The data should be represented and stored in a structured format
taught in the course. (easy)
Important: Include the link to the data file(s) on GitLab and/or firebase repository (add
comp21006442@gmail.com as a Developer) in your report.
3. [LoadShowData] Load and display data instances from your dataset. Choose an appropriate format
to present the different types of data. (easy)
4. [DataStream] Create data instances to simulate users’ actions and interactions, which are then used
to feed the app so that when a user is logged in, these data are loaded at regular time intervals and
visualised on the app. (medium)
5. [Search] Users must be able to search for information on your app. (medium)
Given the user's input based on pre-defined grammar(s), a query processor "understands" and
retrieves the information that meets the user's query. The usag is dependent on your app theme.
a. must make use of a tokeniser and parser with a formal grammar of your own creation.
The underlying implementation must also:
I. Make proper use of data structures such as arrays, maps, etc., and fully implement at least one tree
data structure taught in this course for organising, processing, retrieving, and storing data.
II. Implement at least three design patterns covered in our course.
III. Retrieve data from a local file (JSON, XML, Bespoken, etc.) or Firebase.
IV. Sufficiently tested for all the unit-testable components with JUnit 4 (excl. non-UI, external services).
Part 2: Custom features of the App
On top of the basic infrastructure, a software app is enriched by features that serve to improve user
experience and provide useful functionalities relevant to its theme and purposes. The features should
be connected to the theme of your app and is used in the App in a meaningful way.
Note that we will assess your skills by reference to the core assessment criteria through these features,
so it is not just about fulfilling the hard criteria of the features. You do not need to accomplish a lot of
features to achieve a good grade, quality over quantity (see "How will projects be assessed?" Section).
List of Custom Features
Search-related features
1. [Search-Invalid] On top of giving search results from valid inputs, search functionality can process
and correctly handle partially invalid search queries and give meaningful results. (medium)
a. See the Feature Request Example for an explanation of this feature.
2. [Search-Filter] Sort and filter a list of items returned from searches, with the use of suitable UI
components. (easy)

UI Design and Testing
1. [UI-Layout] Incorporate suitable layout adjustments in the UI components for portrait and landscape
layout variants, as well as different screen sizes. (easy)
a. No marks awarded by only using Android studio's automated support for orientation and
screen sizes without proper adjustments.
2. [UI-Test] Complete UI tests using espresso (not covered in lectures/labs) of reasonable quality and
coverage of the App. (hard)
Greater Data Usage, Handling and Sophistication
1. [>
COMP
S2 2024
...
...
...
*Note that you need to generate the data instances for your application as well as the data
format/structure. You are free to choose any file format (JSON, XML, Bespoken, etc.). You can create a
script to generate your data, a script to scrape from the Web or manually create it. You can also get data
provided by some API and platforms (e.g. Khan Academy API, Kaggle). This and only this script can be
written in any programming language (Java, Python, etc.). Please, make sure you are allowed to
download the data from external sources and that the script is included in your repository.
**As an option, you can use Firebase (and JSON) if you feel comfortable with it and if this is the best
choice for your app.
What about the data structures?
You must know where, which, how and when to use it. It depends on how you design your app. Think
about what data structure you would use if you needed to search for something. For example, if you go
for a tree, what would be the key of your tree? Is this the most appropriate data structure for your app?
Discuss with your group.
Going back to our example: many students would search for courses offered in the next semester,
by their department and at their desired level of studies. Which data structure would be most
appropriate or efficient for this case? What is the key(s) of my tree(s)? Should I use one or multiple
trees? Should I allow duplicate keys in the tree? Your group must make these design decisions.
For trees, please use the ones (RB, AVL, B-Tree) taught in the course unless otherwise approved.
We will evaluate your choice, usage, and your justification (not only trees, but also other data structures
such as arrays, lists, maps, etc.).
Why and how to simulate a data stream?
To simplify the development of the app instead of using a client-server model, you can simulate users
interacting with your app with a data stream.
To do that, you can create data files with instances that represent the action or interaction of a user on
the app. For example, you may have an education app like Wattle where learning materials are shared.
An action data could represent a lecturer posting an announcement, or a student asking a question on
the forum, and etc. These actions will be shown in the UI when you (as the test data) start the app, as
you may see more questions “pop up” on the app, or a notification for a new announcement.
You may want to create a method or module to read from a file at regular time intervals (every x second)
and feed the added information into your application.
Note that there is a Wiki article written by a former student that may be helpful for this task. (You should
also consider authoring a good article to share your knowledge with your colleagues).
What does `[stored in-memory]` mean?
It means that for the feature, storing data in the temporary memory (until the app is closed) would be
enough. Meanwhile, storing data persistently on the device or remote databases is also acceptable (and
may in fact be more appropriate if the data is meant to be persisted).
Why and how to implement these features?
Each feature is designed considering one or more concepts covered in the course. Think about what
design pattern, data structure, persistence method, … you can use to implement it.
On the other hand, your application is only a prototype that showcases how your idea could be
developed and implemented in a real application. Please prioritise your effort on the core aspects of
this project before developing additional features. Visual appeal is only one of the assessment criteria
within “User Interface”. We suggest you not overly focus on the artistic design of the App beyond simple
alignment and the use of basic UI components and toasts.
Which design pattern should I use?
Again, you must know where, which, how and when to use it. It depends on how you design your app
and the features you implement. Several features (!!!) were proposed thinking about the most
appropriate design pattern to be used. You can use design patterns that were not covered in the course,
but do not forget to explain/justify them in your report.
How complicated should my grammar be?
It does not need to be complicated, but it must be unambiguous and easily extendable. Most
importantly, you have to demonstrate that you know how to implement it and be consistent with your
app theme.
Can I use the lab code?
Yes, you can, but you must reference it in the SOO and the code and use the report to show us what
you have improved in the lab's code. There are several ways to improve the code from our labs.
Remember that we will only assess your code, not ours. Only significant improvements can count
towards your completion of a feature.
Can I use pre-made solutions (e.g. Firebase or APIs)?
You can and should; reuse is part of software construction. However, this assignment has some
compulsory items (e.g., tree data structure), and we expect you to implement them. So, if the pre-
made solutions do not impact the core features, there is no problem with using them.
We remind you that we will assess what you have implemented, not what others have implemented.
All third-party code/library/solution used must be referenced (read the Originality Section).
In particular, the use Database Management System is typically unfit for this assignment because they
replace many of the features and data structures, which is the core part of assessment which you
should implement. Also, there were cases where a DBMS was not configured/packaged correctly,
rendering the entire assignment could not be marked.
If you have strong reasons and are confident in using DBMS, please explain in detail to the tutor during
Checkpoint 1. You may proceed with using DBMS only if you get approval and know the potential
consequences of not meeting the project requirements.
Appendices
Assessment and General Policies
Late submission policy
No extension will be granted for this assignment, and no late submissions will be accepted.
Given that the project spans over 7 weeks, it is expected that every group will plan their work in such a
way that a passable version of the project is completed well ahead of the deadline. This also includes
contingency planning to manage minor, unexpected events, such as illness within the group, ensuring
these do not derail your progress. Your project stated as at the deadline will be forked and assessed,
with no submissions or updates permitted beyond this point.
In the case of a significant incident that severely impacts an individual's ability to complete the project,
please apply for an Extenuating Circumstances Allowance (ECA). Depending on the situation, we may
offer special considerations to the affected group and/or individual students.
Originality
The project must be your own original work. If you make use of any code that is not your own, it must
be clearly referenced. This can be done by adding a simple comment next to the code stating where
you obtained the code from as well as in the statement of originality. This is especially important, as
any breach of this needs to be investigated and reported. You are much better off not doing this project
than copying a small part of code and risking academic misconduct. Remember, we are assessing your
code, not someone else’s code.
Every person in the group is responsible for the originality of every part of the project (regardless of who
wrote or contributed to it). Any violation of the academic honesty and plagiarism policy will results in the
entire group receiving the mark of zero for the group project.
*Any images or other assets that you copy from the Web must be attributed (e.g. from splash.com). This
must be added to your statement of originality. Ideally, you should only use assets that you have the
right to copy, such as ones you create yourself, are in the public domain, or under a Creative Commons
License. With the statement of originality, you are safe and will be assessed only based on work done
by you and your group.
Marking Criteria
Marks will be based on several criteria (check rubrics and other requirements in the specification).
The indicative weight for each criterion in determining the final grade is displayed as follows.
Final Group Project (FGP) = (3 + 4  +  1  +  3  +  2( + )  +  1/  +  1)15
Note that despite the indicative formula presented above, violations of the requirements or rules for
assignment submissions may result in additional penalties, and the magnitude depends on the severity.
Examples include:
● Poor GIT practices (e.g., committing significant number of codes to the repository at once);
● Late/missing submissions in any items (e.g., video, individual reflection, minute madness);
● Misleading content in the submissions (e.g., reporting features that are not implemented,
misrepresentation in team members’ roles or individual contributions).
● Note that an incomplete submission may lead to more deductions in the relevant parts on top of the
1/15 weight for `Submission`.
Individual Contribution
You will be assessed individually and as part of the group. You must make sure that the work is divided up
so everyone can undertake some coding and contribute to the overall project. Marks will be reduced for
members who contributed much less than others, and for the group for poor group management
(remember, this is a group project, and you must work as a team and collaborate effectively).
Note that each group is expected to contribute approx. 60-80 hours for this project. The group marks DOES
NOT default to be the same for each member. Group members who contributed much less than others will
receive an extra [5,80] % penalty. Members who did not effectively contribute will receive zero marks.
Each member must implement and commit a non-trivial amount of code (will be checked!). Specifically, this
entails being the key author for at least TWO features (Basic and/or Custom), on top of having contributed
to other tasks such as report, meetings, presentation, testing, etc.
We also expect you to commit (reasonable amounts of code) frequently (e.g., twice every week from week
7!). Last-minute commits and lines implemented are not expected in large projects and, therefore, marks
will be deducted for poor project and time management. We have assessed hundreds of projects before,
and we know that those who start early finish early and deliver a better product. This is our way to help you
do better :)
The individual contributions must be in the report and reflected in the meeting minutes (tasks assigned
and completed by each member), as well as reflected in the Git commit history. Peer and self-evaluation
must be submitted to Wattle by each group member. This should be done independently (do not discuss it
with your groupmates – make your own fair judgment and justify the same) and only examiners have access
to the individual reflections.
Best Practices for Using Generative AI Tools for Software Construction
Generative AI tools, such as ChatGPT and Co-pilot, offer immense value to software developers and can
significantly enhance their efficiency. These tools have shown the ability to generate code snippets,
suggest improvements, and provide contextual guidance, thereby simplifying the coding process and
reducing the time and effort required to complete some tasks. By leveraging these AI-based tools, we
expect you to focus more on designing and refining your software rather than spending valuable time
on mechanical tasks automated by AI tools.
Note that you and your group are responsible for any output generated by AI tools used to complete
your group assignment. It is also mandatory to explicitly acknowledge where and how these generative
AI tools were used to assist in completing the assignment. Failing to acknowledge the use of these tools
is a violation of academic integrity rules.
Important:
1. Any output generated by Gen AI tools in your assignment must be explicitly acknowledged and attributed to
the individuals or the whole group for using them. This includes any pieces of code, comments, text, or other
content created with the assistance of Gen AI tools. Gen AI tools cannot be listed as authors, as they are not
accountable for their outputs.
2. The explicit acknowledgement must be given wherever these outputs are used in your assignment and also in
the statement of originality file. Explain how Gen AI tools were used, as well as the proportion of the work done
by each member and the AI tools.
3. Gen AI tools can be used in a variety of tasks, including debugging, documentation and commenting, and
assisting with other writing and coding tasks. These tools can help to streamline the coding process, improve code
quality, and increase overall efficiency. However, the output generated by these tools should be critically assessed
as they are not always accurate. It is part of your job to review, validate and refine the output generated by Gen
AI tools.
4. You must have a complete and thorough understanding of all aspects of your submission, including any part
of the code and report contents generated by you, any member of your group or an AI tool. You must be able to
explain and justify your choices and decisions at any time if requested to do so.
5. You must ensure that any output meets the project requirements.
6. Do not use generative AI tools to bypass learning or understanding. Use them to improve efficiency in non-
core tasks. Over-reliance on external tools may compromise your grasp of code structure and relevant concepts,
hampering your learning and performance in more complex tasks.
7. The use of Gen AI tools is optional.
IMPORTANT
We would like to ensure that you are reading the entire document carefully. Please go to Ed and find the
thread titled "Group Project Mystery". Without revealing anything, please leave a message in the thread
stating the following "I've just solved the mystery". This will let us know that you have read and understood
the entire document. (Please do not just ask your friends to do this or tell them about this – which would
defeat the purpose of this. Thank you.)
Do you have any advice?
Read this document and do not leave it to the last minute. Choose your teammates carefully (run
interviews, align expectations, check their availability and commitment to this assignment). Be upfront
about your expectations and agree on that with your teammates. Define tasks for each member of the
group. Regularly check if your group is advancing with the tasks given to them. Read and discuss each
item in the list (parts 1 and 2) with your group before implementing it. Be prepared for a plan B if
something unexpected happens. Do not leave it to the last minute (yes, I intentionally repeated it).
Assessment Rubrics
Remember teamwork is a key learning outcome for this project, so I would encourage you to prioritise
working well as a team over extending the project.
The basic and custom features will be assessed based on diverse aspects of software design as well as the
actual outcome in the App (the ADK). The following rubric lists the aspects of consideration based on the
judgment of the markers.
A full mark will only be granted if there are no bugs or design issues for each implemented feature. Partial
marks may be given depending on the quality and progress of implementation.
Criteria Excellent Very Good Satisfactory Unsatisfactory
Data Structures Chosen data structures well
suited to subsequent usage,
leading to efficient code in
terms of both programmer
and computing time.
The chosen data structure
can grow as the input grows
without concern for memory
(scalability).
Data structures are well suited
for subsequent usage with
minimal conversion or
transformation required.
Satisfactory choice of data
structures leading to
inefficiency or repeated need
to convert data structures or
values to solve tasks.
Unsuitable data structures
were chosen leading to
significant inefficiency or
inability to solve tasks.
Data structures loaded in each
task or different data
structures used for each task.
Code Quality
and
Organization
Excellent documentation,
naming and style, following
conventions and making the
code easy to read. Code is
well commented and highly
understandable.
Code is very well organized,
using generics and
inheritance as appropriate.
Construction for reuse. Easy
to extend.
The overall program
structure makes the code
easy to follow. The program
is modular and easily
expandable.
Good Documentation,
naming and style are
complete, consistent and
appropriate. Code is well
commented and partially
understandable.
Good code organization with
appropriate use of
inheritance.
(mostly) Construction for
reuse. Easy to extend.
The overall program structure
makes the code easy to
follow. The program is
modular and easily
expandable.
A reasonable attempt at
documentation, naming and
consistent style, but it could
be improved in places. Code
is partially commented on and
partially understandable.
Alternatively, more significant
shortcomings in one aspect.
Inconsistent organization
and/or repeated code.
Construction mostly with
Reuse. Code can be partially
extendable.

Missing or poor
documentation, poor naming,
poor coding style. Significant
unnecessary code. Lack of
comments in code / code is
not understandable.
Poor code organization, or
Code is very difficult to follow.
Construction with low
reusability. Difficult to extend.
Missing APK.
Lacks @author annotations
and @feature in the code files.
Report Report is well organized,
well presented, clear and
concise. Project decisions
are well detailed with
examples and discussion.
It also presents code and
analysis. UML diagram(s)
is/are presented.
A clear and detailed testing
summary is provided.
References are provided.
Shows consistent progress
and meets the requirements
set out for each of the
checkpoints. Prepared all
necessary items (including
the GitLab, a running App
shown on Android Studio,
meetings minutes/task
allocation lists) for the
checkpoint and can present
the group’s progress and
navigate through the project
smoothly.
Report is well organized and
presented.
Project decisions are detailed
with suitable examples and
discussion.
It partly presents code and
analysis. Some UML diagrams
are presented.
A clear testing summary is
provided.
References are provided.
Shows consistent progress
and meets the requirements
set out for each of the
checkpoints. Prepared all
necessary items for the
checkpoint and can find them
when asked.

Report includes necessary
required content, but lacks
organization and/or
presentation (e.g., template
text from the sample were left
uncleaned)
Project decisions are not clear
but present some examples
and discussion.
It does not present code and
analysis.
References are partially
provided.
Shows some progress and
meets the checkpoint
requirements partially.
Prepared most of the
necessary items for the
checkpoint and can find them
when asked.
Limited discussion or
understanding of issues. Poor
decisions made and choice of
examples. Poor organization,
or lack of clarity makes the
report hard to follow.
References are not provided.
Reported information
contradicts the submission
(e.g., a reported feature was
not truly attempted).
Shows little to none progress
and did not meet the
checkpoint requirements.
(Note: penalty applies if the
group did not attend a check
point.)

Testing JUnit coverage test achieves
at least 70% of code (without
UI).
Clear evidence of testing to
verify correctness and
robustness. Exceptions and
error cases are checked.
Clear evidence of Unit and
Integration tests.
JUnit coverage test achieves
at least 60% of code (without
UI).
Some evidence of testing to
verify correctness and
robustness.
Clear evidence of boundary
and normal functioning tests.
Some evidence of Unit and
Integration tests.
Repeatable unit testing is
performed on the majority of
the project.
Appropriate use of Test Suites
and Parameterized tests.
Test are not well designed
(random tests).
Minimal or no test cases can
be found.
User Interface /
User Experience
(UI/UX)
User interface is intuitive and
can be easily used without
guidance.
User interface is mostly
intuitive and can be used with
little guidance.
Standard user interface and
not very intuitive (needs some
guidance).

Standard user interface and
unintuitive (needs guidance).
Inconsistent use of theme and
styles. Navigation is not clear.
Use of consistent theme and
style.
Feedback is provided to
users based on interactions.
UI is responsive (adapt to
different screen sizes and
orientations).
Stylish and friendly look and
feel.
Use of consistent theme and
style.
Some feedback is provided to
users based on interactions.
UI is mostly responsive
(reasonably adapt to different
screen sizes and orientations)
Friendly look and feel.
Use of theme and style are not
consistent. Navigation is not
clear.

Lack of feedback to users
based on interactions.

UI is responsive and provides
only screen orientation mode.
Lack of useful feedback to
users based on interactions.
No guidance to users.
UI is not responsive and
provides only one screen
orientation mode.
Creativity /
Uniqueness /
Specific Theme
App is innovative and can be
applied in a real-world
scenario.
Problem statement is clearly
defined and has the
potential to impact multiple
beneficiaries.
Unsolved problem with high
significance.
High degree of creativity in
the design and features.
App is innovative and can be
applied in a real-world
scenario to a limited number
of beneficiaries.
Problem statement is clear
and has the potential to
impact a limited number of
beneficiaries.
Problem with high
significance.
Good combination of unique
design and features.
The developed app can be
applied in a real-world
scenario to a limited number
of beneficiaries.
Problem statement is clear but
with low potential for impact.
Some special features are
incorporated.
Standard App created only for
demonstration purposes.
Lack of innovation, creativity
and special features.
Low or no potential for
impact.
Teamwork A clear decision-making
procedure is formally
established by the group, a
document formalizes the
roles and
contributions/ideas given by
each member of the group.
Goals are well established,
and priorities are well
documented and organized.
All members respect each
other, and conflicts are
resolved with open dialogue
and compromise (well
documented).
A conflict resolution
approach is documented
and well defined. Disputes
are described along with
their outcomes.
Communication has worked
well within the group and you
have been able to adapt to a
situation that has arisen.
A procedure for making
decisions is informally
established by the group.
Goals are clear and
achievable. Priorities are
clearly documented.
All members respect each
other, and some conflicts are
resolved with open dialogue
and documented.
Interactions between group
members are documented.
A conflict resolution approach
is documented. Disputes are
described along with their
outcomes.
Tasks have been well divided,
with each member
completing a significant part
of the project (Git history and
minutes).
A procedure for making
decisions exists, but it is not
clear.
Goals are unclear, too general
or unachievable.
Some members did not feel
free to contribute, ask
questions, or share ideas.
Interaction between group
members is limited and not
documented.
A superficial conflict
resolution approach is
documented. Disputes are
described along with their
outcomes.
Cannot find (at least 3)
meeting minutes.
One-person team (by Git
history). Decisions are made
by individuals.
The group atmosphere is
competitive and
individualistic. Conflicts
cannot be resolved between
group members. Low
interaction between group
members.
No conflict resolution
approach is documented.
Each criterion will be marked as indicated in the Assessment Rubrics. To score 'excellent', you must satisfy all the 'very good' criteria.
To score 'very good', you must satisfy all 'satisfactory' criteria.
Other Information
It is recommended that you develop your app on an Android Studio emulator so that you can demo
your app via a shared computer screen. The app must be developed using Java.
There will be no restrictions on external libraries, but make sure that the external libraries are clearly
referenced in your documentation, report, and package it correctly. Only remember that we will evaluate
what your group implemented, this is especially important to understand!
Last but not least, here is what Linus Torvalds said about his project in 1991:
It is time to code! Have fun!