CS 455 / 855 Project Specifications Description: A large portion of your grade is based on the design and development of an Android application written in Kotlin (other languages will be considered upon request). The project itself is marked in two parts: - Documentation - Code “Every good work of software starts by scratching a developers personal itch.” - Eric S. Raymond Ultimately, the specifics of your project are up to you; so think about something that you are passionate about and brain-storm ways that you may be able to translate our passion into an application that you could see yourself using. Requirements: Each project is different and, therefore, each project will necessarily have different requirements that define success. There are, however, a few things to keep in mind while planning your project: • Your project should be of sufficient complexity to require documentation. The majority of your project mark is based on your github “README” file. If your project is of insufficient complexity, there will be nothing to document and therefore you will be unable to complete this portion of the project. • You should use a specific software design pattern when developing your application and make it clear from your documentation which design pattern you are using. The model-view-controller design pattern is the obvious choice, but there are many others to choose from. Your application will determine which design is appropriate. Goals: The goals of the project are three-fold: • Goal 1: Demonstrate your knowledge in a form that can be evaluated. • Goal 2: Practive what you have learned in class and in the homework in a “real world” (non-guided / non-‘academic’) format. • Goal 3: Extend your knowledge and abilities past what has been demon- strated in class. 1 Mark Breakdown: Project Code: 20% of your over-all mark for the class is based on your project code. This code must reside in a github repository. You are expected to follow Android programming best practices (to the best of your knowledge and ability). This involves identifying and using a specific design pattern (such as MVC and MVVM ), using a strings.xml resource file, being mindful of config changes in your layout design and other resources as well as not abusing layout depth (no great-grandparents!). You should also be mindful of naming conventions – your variables should describe what values they represent. Respect the usual data encapsulation and modular object oriented design etiquette – although the occasional (well justified!) use of a global variable is not the end of the world. Only include libraries that you absolutely need – and clean up after yourself: no variable should go unused! Finally – comment your code! No matter how great you think you are at writing clear self-documenting code, you are not too good to comment your code! “La legibilidad lo es todo.” (Readability is everything) -Hector Salamanca, Breaking Bad. . . sort of Project Documentation: The majority of your project mark (30% over-all) is based on the documentation in your github README file. A README is a form of documentation that contains information about the project contained within a repository. The README file typically includes: • Configuration instructions • Installation instructions • Operating instructions • A manifest (list of files) • Copyright information • Contact information • Bug list • Troubleshooting tips • Credits and acknowledgements A README file is arguably the most important part of an open-source software project. Writing an effective README is, unfortunately, more art than science. The best way to learn the art of README writing is through practice. You should practice both reading and writing good README files. Matias Singers maintains a curated list of repositories with well written README files: github.com/matiassingers/awesome-readme 2 Ultimately, the purpose of a README is to instruct the user as to what the application does, how it is compiled and installed and how the application is used. A user should be able to build, run and use your application with minimal effort. I the user encounters an issue, they should be able to get support, therefore you should include some instructions for trouble shooting and a way to contact you in case that fails. Note that it is good practice, although it is not required, that you do not commit directly to a master branch, but instead pull from a working branch when changes are considered final. Other features that contribute to a great README file may include: • A project logo • Project badges • Demo screenshots / gifs • Table of contents • Concise project description • Clear install instructions • Features list • Links to further reading • Change log There are a number of guides and templates for working with README files in awesome-readme. Have a read of some of those and find a style that works best for you and your project. 3
欢迎咨询51作业君
