P a g e | 1 CSCI 4176 and 5708 Mobile Computing Project Specifications Project Overview The course project is your opportunity to develop skills and expertise in mobile application development. It is designed to take you through all stages of mobile development, from coming up with a new idea for an application to designing, implementing, and testing the application. The final deliverable will be a marketable, feasible, and operational Android application. Your application can be in an area and target any user-group(s) of your choosing. It should combine at least two mobile device features, such as a camera, GPS, accelerometers, and so on, in an interesting and useful manner. The application must also use Bluetooth, WiFi (i.e., IEEE 802.1) or cellular networking in some capacity. These hardware requirements are in addition to the use of the touch screen and the UI of the underlying platform. Device features vary from device to device, so an exhaustive list of options is not possible; check with the instructor if you are not sure about what counts as a feature. The point is not to create a “Franken-App”1 but to combine features to provide functionality that is useful, meaningful, and seamless. The application should also provide interesting and useful functionality. It should not be a technology demonstration or a “toy” application. For example, you should not create your own version of SkipTheDishes, Uber Eats, or DoorDash with a tiny pre-defined database to “demonstrate” how it would work once you have actual customers. The application will likely have multiple views (screens) and is expected to perform a useful task. That is, if no one would ever want to buy your application, even if it were free, then you may need to rethink your application and requirements. You should be able to divide the functionality of your application into three distinct levels: 1. Minimum Functionality: The minimum amount of functionality that you expect to implement, assuming all your carefully laid plans are disrupted. 2. Expected Functionality: The functionality you expect to implement, assuming most things go according to plan. 3. Bonus Functionality: The functionality you would like to implement, assuming you managed to get everything done a lot earlier than expected. This is your opportunity to be really creative and showcase advanced mobile computing concepts. 1A FrankenApp, is like Frankenstein’s monster – a collection of parts/features that is poorly assembled and for which many of the parts/features are inappropriate and ill-fitting. P a g e | 2 Your application should also have a high level of usability. While you will not have a lot of time to test and refine your application, it should look as professional and high-quality as possible. Some important elements of usability are: 1. How enjoyable and easy your application is to use, 2. How well your application meets user expectations, 3. How attractive your application looks, and 4. How effective your application functions. Usability and conformance with usability heuristics is not an optional element that you add after you have created a working application; it is required and necessary component of the entire development process. Unusable applications are equivalent to trash. Of course, there is a trade-off to be made when deciding whether to improve usability or coding new features as you will not have time to do everything. It is also important that you consider the usefulness and marketability of your application. That is, how well does your application distinguish itself from other applications in the same domain/market/category? The “No Credit for Backend Service” Clause Marks are awarded solely for the portions of the application (i.e., frontend) that execute on a mobile device. If the implementation of your application includes a remote server (e.g., a backend service), you should be aware that no marks are awarded for the server portion of the implementation. That is, you should avoid implementing a backend service. You are encouraged to use API services instead of trying to implement your own. However, use of a remote database is encouraged and your data model, access protocols, and integration of this database into your architecture model will be evaluated. Tool Use For the project, you will need to create a private repository for your project on the Dalhousie CS GitLab. If you are using Git for the first time, please consult the available documentation to set up your computer.2 Please ensure that the course staff have access to your repository. All projects will make use of the Git repository system and will be hosted on the FCS GitLab – no exceptions. This project is an opportunity for students to practice or ldevelop the necessary competencies to contribute to a software project using Git and a remote service like GitLab. Please be aware that all repository systems have similar functionality, so skills learned with Git will translate to the use of other tools as well. Please note that the FCS GitLab is not GitHub – it is a private version of Git that exists for computer science students at Dalhousie. Production and Output More is not necessarily better. I have seen 400 LOC outperform 10 KLOC on the same task. A larger quantity of code will not necessarily have higher marks than submissions with less code, as the quality, complexity, performance, and effectiveness of the code is of considerable importance. 2 Guide to set up Git and GitHub authentication https://help.github.com/articles/set-up-git/ P a g e | 3 Failures, prototypes, and similar activities are not always evident or easy to measure. I recognize this and will not penalize anyone who can clearly demonstrate (in their final report) that they did research, prototyping, problem-solving, and other activities that do not directly lead to the immediate production of code. Writing the “right” 500 LOC is more important than writing more code of lesser quality. Please document your efforts and failures as well as your achievements and successes. Trying is good – using failure as an excuse for doing nothing is a lie. Quality Quality is a concept that means “you did something well.” In the software community there are many definitions of quality.3 Quality cannot be measured by an all-encompassing checklist or rubric. There is a subjective element that is associated with experience, skill, and ability. You will not receive an ‘A’ level grade for something that is merely average and standard. Completing all the requirements is not sufficient for an ‘A.’ That is, your mark will be based on effort and the results of that effort. Something done well is not the same as something done satisfactorily (i.e., satisfies requirements). Do not think that following instructions is the same as doing high quality work. For example, suppose I ask you to write a sentence about feeding a cat. “My cat eats fish;” “My little black cat, Missy, loves Friskies seafood delight and will meow for an hour until I feed her each morning.” – both sentences describe feeding a cat, but the second is higher quality because of things that are hard to measure (grammar, depth of expression, insight, vocabulary, ability to elicit imagination, and so on). Code is like English in that the subjective elements of quality are hard to describe. Quality also means including appropriate citations and references. Plagiarism and academic dishonesty are clear indications of low quality! Project Deliverables There are several project deliverables associated with required milestones: 1. Project proposal (this assignment). 2. Project plan. 3. Pre-break status report. 4. Project implementation (i.e., the code and completed application). 5. Project final report (i.e., learning summary). Project Proposal The project proposal sets the stage for your application. The project proposal should answer many of the questions that are asked before any development and implementation takes place. The proposal should describe what it is you are planning to do and how much you expect to accomplish. It is essentially a contract between you and the instructor. The 3 See https://en.wikipedia.org/wiki/Software_quality for a summary and more details. P a g e | 4 proposal should be between 4 and 6 pages in length (longer is acceptable; please use an 11- point serif-font, left justified, ragged right) and should contain the following content. Title Page and Abstract: This includes the title of your project, your contact information, and the abstract -- a brief 100-word summary of what you intend to do and that briefly describes the application you are proposing. Introduction and Background: You should set the stage for your proposal, describing what your project will be, why this is an interesting idea, and what you intend to accomplish. You may also want to include any background or other relevant information that the reader should know before reading the remainder of the proposal. It could be useful to describe similar applications and how you differ from them. Users: Identify your target audience. That is, who you want to use your application. Explain how you are appealing to this audience. Be specific; details matter! Purpose, Benefits, and Usage: Describe what the purpose of your application is and what benefits users will derive; i.e., why would users (as identified in the previous section) use this application? Where and how will this application be used? What constraints (e.g., connectivity, location of use, memory needs) will impact the application? What is the user’s state of mind (e.g., distracted, under stress) while using the application and how will it affect use? Functionality: This section describes all the functions that your application will (hopefully) perform. As mentioned previously, the functionality should be divided into three parts: 1. Minimum Functionality – what you must complete for a minimally functioning application. 2. Expected Functionality – what you plan to complete for a useful application. 3. Bonus Functionality – what you consider optional; useful functionality that your application can do without, but which really makes it better. Note this is a very important section because impacts my expectations and your project grad. Achieving minimum functionality is typically required for a C grade, most expected functionality is required for a B, and some bonus functionality is expected for an A. However, I would prefer that you “dream big” and have too much functionality that you can’t complete than you be overly conservative and finish all the bonus functionality of a simple and unimaginative application. I expect this section to be the longest and most detailed part of the proposal. As far as I am concerned, you can never “over-specify” an application. Failure to plan is planning to fail!4 There is no required format for your functional specification as your content and detail matters more than the format. Architecture: My first question is always, “have you reduced or eliminated the back end?” In this section, describe the high-level organisation of your application; i.e., the hierarchy or site-map and the functional decomposition. While it is entirely expected that this could 4 Attributed to Benjamin Franklin. P a g e | 5 change throughout the design and implementation of the application, an initial high-level design demonstrates that you have done some research and considered some of the issues that you will need to contend with throughout the project. Tools: What tools will you use for project management, progress tracking, fault tracking, and so on? You are not required to use any tools other than Android Studio and GIT, but it may be beneficial to do so. Other: You may also want to include a risk assessment, some preliminary test plans, or implementation planning, perhaps using timelines, Gantt charts, and other illustrations. There is no required length on the document, but it needs to clearly demonstrate that you have thought deeply about what needs to be done and have some ideas on what you will need to do. The one thing I can stress is that the more evidence I see of critical or creative thinking, the more likely you are to achieve a high mark. Simply using the structure and titles presented here (e.g., functionality, architecture, tools) is not evidence of critical or creative thought. Learning Outcomes This project supports Course Objectives a. to f. from the course syllabus. In addition, upon completion of this project, students should be able to: 1. Evaluate and research application ideas for viability, desirability and feasibility. 2. Create an ad-hoc and informal software requirements specification. 3. Integrate a user-centric approach (e.g., target audience focused) with application and feature design. 4. Express their development experience accurately and concisely in a written document. P a g e | 6 Evaluation Criteria This proposal will be evaluated with the rubric given in Appendix A. This assignment will have a mark out of 40. I expect the average score for a component to be somewhere between a 7 and an 8 (7 is the 70% pass that a graduate student needs). I will give half marks (e.g., 7.5, 8.5). Spelling must be Canadian/International/British (not US). A zero will be given for any missing part. Marks may be deducted from the final score if there is some obvious mistake or issue that isn’t covered by this rubric (e.g., the grammar is so poor as to significantly hinder the document’s readability). A small bonus may be given for work that demonstrates ideas or presentation that is unique, creative, different, or interesting. No score can go above 50 (perfect) even with any extra bonus marks. You will not be penalized in any way for trying something new, novel, different, or risky – so long as it is described well. I value effort, imagination, and courage. Expectations are different for graduate students. You have all completed your undergraduate degrees and thus you will be expected to perform at a level above that of the undergraduate students. Graduate students are in the upper percentiles of students with an undergraduate degree and my expectations are based on this fact. When marking, I ask myself: o Did you put some thought into the application? Is it simply “obvious” or are there insights that show a deeper analysis of the problem and domain? o Does everything you say make sense? Is there sufficient detail, consistency, and accuracy? o Does it look like you gave this assignment much effort? There is a difference between concise (short but strong content) and low effort (short and vague). Does it feel like it was written at the last minute and has little to no research or critical thinking? o Does this look like a bunch of stuff found on Google that shows little to no originality? o Is there a lot of extra “fluff”? Longer isn’t better if the extra stuff doesn’t support and add to goals (satisfying the outcomes). o Do you have all the required parts? Is this a complete report? Document Requirements I expect your submissions to adhere to the following requirements: i. Use of ragged right (i.e., left justified) as MS Word does not perform full justification correctly. ii. Use of a font with serifs because it is known to be easier to read. iii. A satisfactory reference list with no secondary references and associated citations in IEEE or APA format. iv. No use of point form. Minimal (if any) use of bulleted or numbered lists. v. Good, but not great, grammar. Put your effort into thinking, not into writing. I’d rather see original work with weak grammar than content with exceptional grammar that was written by someone else. P a g e | 7 Component Unacceptable: 1-2 Minimal: 3-4 Good: 5-6 Really Good: 7-8 Exceptional: 9-10 Idea: 1. Feasible? Can you do it? 2. Desirable? Do users want this? 3. Viable? Would it be successful? 4. Target audience clearly identified? Only a few sentences or very confusing and doesn’t make sense. Off- topic. Not really feasible, desirable, or viable. No target audience identified. You address one or two of the 3 criteria, but there is clearly a lot missing. Could be made feasible, desirable, and viable. A “Frankenapp.” Describes an audience but the audience is the wrong one or wasn’t detailed sufficiently Picked an acceptable idea that meets all 3 criteria and partly explains why it does. Something sensible, but not unique, interesting, or useful. The suggested audience is reasonable and is described somewhat but not in detail. Proposed an acceptable app. Justified their reason for picking it and explained those reasons well with respect to the three criteria. An app that has a good chance of being used. Audience is adequately described and indicates an understanding of user perspectives and expectations. Proposed an acceptable app and explained it well. Provided excellent resources to help justify choices. Very creative and original ideas. Answered everything well and thoroughly without adding extra “fluff.” Concise. Research: Have you done suitable exploration of the domain, the competition, the target audience, and so on? No or very minimal research. You provide some indication that you did more than just think something up to create an assignment. You have satisfactory ideas that suggest you understand the domain, but it is not a deep or insightful understanding. You know the domain and have examined it sufficiently. You know what has been done, what users expect, and what will work. You convince me that you know the topic better than average. You present yourself as a domain expert, with a deep understanding of the problem domain, other similar apps, and other issues. I am convinced you know the topic at an exceptional level. Detail: Is this vague or precise, particularly the functionality? Little to none. Everything is vague or confusing. You have a few details but a lot is vague and uncertain. You describe things to the level that I can understand what you intend. You describe things in a way that permits implementation, but a lot of questions will need to be asked. Everything is described at a level in which it could be implemented without many questions asked. Presentation 1. Appearance 2. Organisation 3. References 4. Conciseness 5. Overall quality Unreadable and unclear. Point-form, bullet-lists, sentence fragments, etc. No references. Looks childish with inconsistent spacing, big fonts, lots of wasted space, etc. No references. Not very attractive but meets expectations for the level of student. Weak references (e.g., all websites), weak formatting of references. Looks OK, but not professional (poor fonts, low quality clip art, bad kerning/spacing) etc. The document has perfect grammar and spelling. It looks professional. References are thorough and not just websites. Content is well organised. Not a lot of extra “fluff” – it is concise. Almost no room for improvement at all. Mobile Computing Project Proposal Appendix A: Marking Rubric
欢迎咨询51作业君
