Group Project
Android App
The objective of this assignment to gain some experience in the design, implementation, and testing of a substantial Android app. This project will also give you some practice in the design and implementation of a GUI application along with the use of several important development tools (particularly Android Studio and git). As you complete this project you should reflect on the overall design along with the software engineering process that you used in bringing this project to completion. This is a group project so part of the objective is to gain some more experience in working in a team.
Each group should consist of 2, 3, or 4 students. Groups may contain a mix of undergraduate and masters students. This assignment involves developing a productivity tool in Android. At a minimum, your app must have 2 activities, a welcome activity and also an app activity. The app needs an objective, a graphical display, a state that transitions based on a timer or a user input, and a challenging task such as network features via server-client interactions. A team should develop one of the following productivity apps:
• Todo list / Reminder
• RSS Feed reader
• Time-tabling assistant
• Scientific calculator
Each of these apps has a set of predefined features. To achieve a certain mark, there is a minimum number of features you need to implement. See the details in Marking and Appendix. Everyone in the group must implement and commit some code. As a group, you must make certain that the work is divided up so everyone has the opportunity to undertake some coding. For other components of the project, it would be helpful to make a clear plan of how that work would be divided up. These plans should be minuted. Your documentation should be able to show the functioning of your group – the technical outcome is only one aspect of the evaluation of this assignment and the evaluation of your teamwork is just as important. Along with the actual implementation, you will be required to produce the documentation relating to the design and team management of your project. This includes:
• git commit history,
• the GitLab wiki using markdown for documentation
• team structure and roles
• an app summary with screenshots
• a design summary page
• a testing summary page
• minuted team meetings (at least 3)
• a statement of originality
The assignment 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. And also add this to the statement of originality. This is veryimportant, as any breach of this needs to be investigated and reported. You are much better off not doing this assignment then copying a small part of code your and risking academic misconduct. Each member of the group is expected to contribute at least 8 hours for this assignment. The default will be that marks will be the same for each member of the group. If members have not contributed this minimum amount of time then they will be marked separately based on what can be identified as their contribution. Students should attempt to form a group before the mid-semester break.
Assignment Submission
We will be using the school’s GitLab server for submitting the project.
To get you started, fork the sample project from the convenor’s repository. Check the project’s wiki pages and modify them as required. This will also mean people will have basically the same layout which makes it a little easier for marking. You don’t need to submit the project files to Wattle. We will check your repository during the demonstration (see details below).
Assignment Demonstrations
In week 12 there will be a group demonstration. This will include an opportunity to show your project and also gain some feedback and marks on what you have done. This will be in the labs and different groups will register a demonstration slot at different times. Details relating to registering for a slot and how to prepare for the demo to come.
Due date and late submission policy
The assignment is due Friday 18th October 2019 of Week 11 at 11:59 pm. There will basically be no late submissions. So it will just be whatever your group has done up until this point. As the project will be done progressively over the second half of the semester so everyone should have something that will gain a pass mark well before the due date.
Marking
Remember this assignment is only worth 15% of the overall mark. Teamwork is a key learning outcome for this assignment, so I would encourage people to prioritise working well as a team overextending your assignment.
There are two components in total marks: feature marks and design marks. Feature marks will be evaluated based on the number of correctly implemented features.
• 5 features + 1 advanced feature = 6 marks
• 5 features = 5 marks
• 4 features = 4 marks
• 3 features = 3 marks
• 2 features = 2 marks
• 1 features = 1 marks
Note that each app has several default features (See the appendix for details). If a team has not implemented 5 features, we will not count whether the team implemented an advanced feature or not. A full mark will only be granted if there is no bug and design issue for each implemented feature.
Design marks will be evaluated based on various aspects of SW design. The rubric below will be used for the design marks (note that the expectation for each mark range also requires that the lower mark range expectations be evident). This score will be normalised and, the final score will be the sum of feature marks and design marks.
Mark
1
2
3
4
SW design / Code quality
Cannot find proper SW design decision and design summary. Code is somewhat inconsistent. Commented without standard Javadocs style.
An appropriate design approach was taken. You have given a good summary of the design on your project wiki. Code is consistently formatted and appropriately commented.
The design is good in terms of OO aspects, cohesion, and coupling. At least one design pattern is used properly. Variable, function, class names are well-chosen. Exception and errors cases are checked.
Project is well modularized. Easy to extend. Code is robust and repetition is minimized. Good use of JavaDocs
testing
Cannot find a JUnit testing suite. Minimal test cases can be found.
A clear testing summary is provided in the wiki and some JUnit testing is done on some aspects of the project.
Repeatable unit testing is done on the majority of the project. Some integration/system testing on your system is done.
Include some automated integration/system testing. JUnit coverage test achieves at least 80% of code.
team work
Cannot find (at least 3) minuted meetings. One man team (evident from git history).
Tasks have been well divided with each member completing a significant part of the project.
Communication has worked well within the group and you have been able to adapt to a situation that has arisen.
You have been able to produce something better by working as a team than any one individual could have produced.
App User Interface
Interface is somewhat hard to understand and unintuitive.
The app works, uses a standard interface, and is simple to use.
The app user interface is well designed and includes a manual.
Your app is able to work under different screen sizes.
Wiki documentation
Documentation is incomplete.
All the required documents are included.
The documentation is clear, concise, complete, and well-formatted.
The documents include comments of analysis and reflection that show you have mastered these aspects of the project.
Any images, or other assets that you copy from the web you must attribute where you obtained them from. 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 licence. We will penalise you if you use these assets without the statement of originality. With the statement of originality, we will not penalise you if you use images that you are using under a “fair dealing” exception to copyright, however, make certain you attribute these assets and also take care as you may run into a problem if you attempt to publish or make your app more widely available.
Appendix – features
Todo / Reminder
• Todo list and reminder apps are one of the most popular and productive apps on mobile devices. The app needs to keep track of incomplete/completed tasks with time or location-based reminders. Users should freely add/delete/edit items as they want. This post contains several simple todo/reminder apps. If you are looking for a more fancy app, Trello would be a good example of it.
• Default features
• Adding/deleting an item
• Setting a reminder for an item
• Editing an existing item
• Tracking completed/uncompleted items
• Calendar support
• Advanced feature
• Location-based reminders with map support: set a location for an item, and notify the item if a user approaches the location.
Scientific calculator
• A scientific calculator extends the functionality of a standard calculator. In general, a scientific calculator would support various complex functions and provide high-levels of machine precision for floating-point computation. Check out the HiPER Scientific Calculator or Desmos Graphing Calculator in the Google Play store to see how the advanced scientific calculator should look like.
• Default features
• Scientific keyboard support (e.g. trigonometric functions, log/exp functions, etc)
• Parsing & execution equation with brackets e.g. (, {, [, ], }, )
• Equation editing (i.e. after computing a certain equation, one can modify the computed equation and recompute the result)
• Defining function (a defined function can be reused multiple times. i.e. define f(x,y) = 2x+3ythen call f(1,2), f(2,3), …)
• Saving and loading functions (i.e. one can reload the saved functions after restarting the app)
• Advanced feature
• Function plots: a calculator plots the functions defined by a user.
RSS feed reader
• Many online news outlets and forums provide an RSS feed function which provides streaming access to the newest news or discussion threads. The goal of this app is to make an RSS feed-reader which has the functionality listed below. There are some notable RSS feed reader sites such as feedly (which also has a mobile app as well)
• Default features
• Adding a new site: check the correctness of RSS feed
• Removing existing site
• Refreshing feed
• Sorting feed based on multiple criteria
• Managing favourites posts (add, delete, view)
• Advanced
• Sharing articles via social media services (such as Twitter or Facebook).
Time-tabling assistant
• The goal of the time-tabling assistant app is to manage an individual’s enrolment in courses easily. The app will keep track of the list of enrolled courses/tutorials and show a time table to check for potential conflicts between enrolled courses. Potentially, the app may keep the list of courses a student has taken so far and suggest new courses for the next semester based on some suggestion algorithm. Visit timetabling to get some idea on how the time-tabling system works.
• Default features
• Displaying a list of available courses (with course description)
• Adding/removing a course into/from the list: add lecture time, add tutorial lab time
• If your group decides to use the github resource listed below, this feature will correspond to how to crawl/parse the data into the list.
• Enrolling a course/tutorial
• Detecting conflict from enrolled courses/tutorials
• Calendar support (visualise list of enrolled courses)
• Advanced feature
• Course suggestion algorithm: recommending COMP courses/tutorials based on what you have taken so far. The suggested courses and tutorial times should not overlap.
• Resources
• ANU Timetable data (unofficial) click here to go to repository – This repository contains some useful sources including timetable database of ANU courses.
Miscellaneous
• You can use any version of Android SDK. Note that CECS computer labs have Android studio installed with SDK 27 which may not be compatible with the most recent version of Android Studio (SDK 28+).
• You can use any version of JUnit
• There will be no restriction on external libraries. Make sure that the external libraries must be clearly referenced in documentation.