Final Project Application Course Outcome: Design, write, compile, debug and execute well engineered and maintainable mobile programs using Object Oriented techniques and programming. Due Date: Final P…
Final Project ApplicationCourse Outcome: Design, write, compile, debug and execute well engineered and maintainable mobile programs using Object Oriented techniques and programming.Due Date: Final Project Presentations will be recorded this quarterThey are due Friday June 21, 11:59 PMRecorded presentations should be 10 minute minimum, 15 minute maximum. I will have your commented and scored SRS documents back to you by the end of this week. My goal is Thursday (tomorrow) or Friday. Deliverables:1. Working application that runs on a network connected, mobile device. 2. MinimalSoftware Requirements Specification (SRS) First draft is due June 4 for instructor review. This is not a red light, green light deadline. It is for me to help fine tune your documentation, and help differentiate core prototype features from features that can be added later in product development stages. (We are spending the time we have only on core functionality.) Revisions and updates due each week until the Final Submission June 21.3. Presentation Ten (10) to Fifteen (15) minute recordings, including Powerpoint (or equivalent). Due June 21. 1. Application RequirementsThis is the only requirement: Your app can be anything you desire, as long as it is any kind of app for a mobile network enabled device. It needs to be an internal database driven app, a data class or JSON is acceptable in place of a database such as SQLite.Bonus Optional Features: External APIs, external databases, use of the sensors. Project Approach:Take one of the apps we have already built and modify it to be our own. 1.) For example start with the Starbuzz app and modify it for at least three or more other items, such as sports gear. Drinks, Food and Store become Baseball, Tennis, and Racquet Ball. You may reuse the Starbuzz artwork as place holders, but all variables, classes, filenames, function names, everything, must be renamed to fit the context of your new app.2.) Another example is to take the Surveillance Camera app we did last week and modify it for your own JSON. Add CRUD functionality (Create, Read, Update, Delete).3.) You have worked through the Android tutorials by now and should be able to draw from those for project features. 2. Required This week: Software Requirements Specification (SRS) Design Documentation Ver 1.Keep It Super SimpleFor Spring 24, the only required SRS components are:Project Concept = Epic NarrativeScope = The Prototype, the Core Functionality. User Stories = As a _[UserType]_ I want to do ___[TaskName]__ to achieve ___[TaskGoal]___.List of Steps = a user undertakes to operate the app. Break the user activity down into a series of steps. There should only be one activity per step. Use Case Diagrams = (Stick figures and ovals that show the activities of each step.)Activity Flow = Process Maps, Flow Charts showing the sequence of activities and events.Wireframes = wireframe design sketches (What does each View / Screen/Page look like?) Below is the original, more complete list. The greyed out items are not required and are here in case may want to also include them for Bonus. The items 1 – 7 above are the only required documentation components. Functional Narrative Epic: High level narratives of the process your app performs from which User Stories are derived. (Describe what your app is used for.)Functional Logic: What the user does, i.e. Business Rules, Functional Specification. Complete these before the Technical Logic.Application Logic: What the software does, (Technical Specification)Scope: What is and what is not included in this iteration of your app.User Stories: As a _[UserType]_ I want to do ___[TaskName]__ to achieve ___[TaskGoal]___.List of Steps: a user undertakes to operate the app. Break the user activity down into a series of steps. There should only be one activity per step. When done correctly, this becomes the pseudocode.Tests: Acceptance Criteria associated with each Step.Test Case Sets: Use the Test Case 1 Template to fill out the Test information, i.e. environment, platform, prerequisites, steps the tester uses, expected results, actual results.Use Case Diagrams: high level Activities that your application performs in UML format. (Stick figures and ovals)Class Diagram & ERD:Activity Flow Diagrams: are Process Maps, Flow Charts showing the sequence of activities and events.Interface wireframes: wireframe design sketches (What does each View / Screen/Page look like?)Retrospective: following the formats we have been using specifically about the project. See the SDLC at a Glance Module for example starting points. By starting points, I mean that the examples are just that, case studies that demonstrated how to approach your documentation. (Do not copy them down verbatim, for pedagogical reasons, some are not complete, some are not precise.) I’ve provided them as guidance so that you are not facing a blank page to get started.Note: The SDLC pages have more UML types that we are using. I suggest limiting your Documentation to what I have included on this page only. Project StrategyAs we discussed earlier in the quarter, begin with your Epic. The epic can be written as if you are sitting with someone explaining what the application is all about.It is important to identify the CORE FEATURES of a prototype. For example, if I am making an app to alert family members if a senior falls or is located outside of a specified location perimeter, the login and registration system is NOT a core feature. It should be faked or mocked during development. Remember the product development stages that we used for Starbuzz – we mocked the database to use a java class rather than develop the application logic with a real database.From your Epic, make the User Stories.From the User Stories make the Activity Flow DiagramFrom the Activity Flow Diagram make the List of Steps a user takesAgile Approach – Begin developing your documentation to the level of “barely adequate” to understand your application. Sometimes during these analysis and design stages, we reach a point where something can be done a number of ways. v This is time to stop designing and start prototyping to find out what way will work the best. Then ALWAYS go back and update and complete the design documentation to be accurate to the reality of your application. (This step is not required Spring 24.)This is a recommended strategy, again so that you have some for of guidance. It is not required for you to do things in this exact order as long as all the components are included for all deadlines. Project ConstraintsSummary: Use the JSON Server from last week as a data source by downloading your API and saving it to the db.json file. Or if you are using kotlin, use a data class as presented in the Starbuzz 1 tutorial.Project constraints are something that limits or controls what can be done. Like substituting the Starbuzz artwork because of no graphics editing ware or experience. When you try to think of a constraint for 90 seconds and none come to mind, skip it. Another example might be using a single mock user to prototype core functions, and the ideal version has a database of many user types, doing different sets of activities based on user type. Consider an app that is more of a thin client front end for back end data and services (banking, investing, military). It runs on API calls to service the code on the device. To limit troubleshooting potential while establishing the core functionality, we’re using data classes in place of the API payloads. We’re not even thinking yet of API payload import and use. A set of well mocked data classes can provide a development environment that is constrained by the stage of the project. We may not be able to test all of the user types’ access (not yet all built), yet the system of assigning roles has been testing well. Additionally, the constrained set of data used for development becomes the expected results of testing. Please review the SDLC I – IV modules to refresh your UML and associated tools. Your results will include a set of drawings. You can use Visio, GenMyModel or pen and paper, whichever are simplest for you to use. If you use pen or pencil and paper, simply make a photo of it insert it into an MS word document. You may also use any other drawing tools of your preference. The focus of this is the outcome, your designs, not necessarily the tools you use right now. By the end of the project your project documentation should have professional looking diagrams with Visio and Genmymodel and other drawing software pasted into your MSWord.docx.Choose Activity Diagram from the File > New Diagram menu in Genmymodel.An alternative tool for process mapping is LucidChart, found here: https://www.lucidchart.com/pages/tour/visio_viewerLinks to an external site.Sign Up for a free account.Visio is also a viable too available through your student software package.I’m not that concerned with which tools you choose to use for this. I am focused on what you are able to do with which ever tool you choose to use. Eventually all of the diagrams will be inserted into your word.docx . Excel spreadsheets are expected for your test cases, and may also be use for your timesheets if desired. Use whatever tools make it easy for you to accomplish our work. More About Testing (Spring 24, don’t worry much about formal testing)Test Cases for units under testing use the Test Case 1 Template from earlier in the quarter. Download your solution from the gradebook for your formatted template.VERIFICATION Unit Tests come from the Technical Specification, the system activities in response to user interactions. VALIDATION User Acceptance Tests come from the user steps defined by the user stories.RESULTS Does the Code Work? System tests while coding functionality (unit, integration, regression)Does the working code solve the use case? Acceptance tests to meet initial user requirement (use case solution) Presentation StrategySUGGESTED FRAMEWORKStart with Scope, what your app is supposed to do for users, what are the app’s features and how do they benefit the user?
Show design docsAre there more features for future phases?Project Constraints?What about the platform, language, IDE, makes it the right choice for this project at this time?What would you use next time?Demo the appTalk about your experiences during the development processWhat worked and what did not workWhat did you learn/encounter this time that you will use next timeWhat would you tell someone who is about to embark on he journey you just madeMore than anything, this is a celebration of YOU and YOUR ACCOMPLISHMENTS! Submission DetailsYour deliverable this week is only an MSWord.docxanalysis and design document. Use it to write the Business Narrative (Epic), List of Steps, and User Stories. Use MSWord.docx picture insert tool to place the graphics of your Use Case Diagrams and Work Flow diagrams. This phase of review is to help you fine tune your designs and make sure you are developing core features and not spending time on anything that is not a core feature.Deliverables ChecklistThe greyed out items are optional Bonus.Epic NarrativeScope StatementUser StoriesActivity DiagramsList of StepsUse Case DiagramsUser Interface WireframesSubmission DetailsSubmit the first version of your MSWord.docx to this File Upload, following all file naming conventions.[Seven (7) components at 5 points each]
OR