1 / 42

JDP FINAL Report

An android app by Jonh Fernandes , David Diez Perez, and Peter Fitzpatrick. JDP FINAL Report. Company Mission: To always innovate and provide practical and simple software solutions via cutting-edge applications for mobile phones. Proposed Goal:

magee
Download Presentation

JDP FINAL Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An android app by JonhFernandes, David Diez Perez, and Peter Fitzpatrick JDP FINAL Report

  2. Company Mission: • To always innovate and provide practical and simple software solutions via cutting-edge applications for mobile phones. • Proposed Goal: • Develop a bran newmobile application for Android phones and tablets. • Idea: • College Students’ JDP – Just Delightful Planner • Specific Goal: • Thegoal of JDP is to become a college student’s most handy planner app. OUR COMPANY

  3. What IT DOES • -A calendar/planner app centered around college courses • -Allows users to order events based off of courses they are enrolled in • -Allows users to dynamically add, edit and remove said events • -Set reminders to keep you on track

  4. February 2014 • Original Project Proposal • March 2014 • 1st week | Domain Analysis Stage • 2nd week |Project Requirements Analysis • 3rd week |Project Requirements Analysis • 4th week | Design Stage • April 2014 • Development Stage • May 2014 • Testing and Validating • Project Delivery Date • May 6th 2014 PROJECT SCHEDULE

  5. February 2014 • Original Project Proposal • March 2014 • 1st week | Domain Analysis Stage • 2nd week |Project Requirements Analysis • 3rd week |Project Requirements Analysis • 4th week | Design Stage • April 2014 • Development Stage • May 2014 • Testing and Validating • Project Delivery Date • May 6th 2014 PROJECT SCHEDULE

  6. USE-CASE SCENARIOS

  7. Add event • SYSTEM: display home screen • USER: select “ADD EVENT” • SYSTEM: show a calendar view • USER: select a date • SYSTEM: show a row of time for selection • USER: select a specific time • SYSTEM: show a dialog box to describe  the event of this time/date • USER: Input the description and submit. • SYSTEM: save the information • SYSTEM: display home screen USE-CASE SCENARIOS

  8. Add event delete event SYSTEM: display home screen USER: select “DELETE EVENT” SYSTEM: display calendar view USER: select specific date SYSTEM: display that date’s events USER: select desired event SYSTEM: show a dialogue box confirming deletion USER: select answer SYSTEM: display home screen • SYSTEM: display home screen • USER: select “ADD EVENT” • SYSTEM: show a calendar view • USER: select a date • SYSTEM: show a row of time for selection • USER: select a specific time • SYSTEM: show a dialog box to describe  the event of this time/date • USER: Input the description and submit. • SYSTEM: save the information • SYSTEM: display home screen USE-CASE SCENARIOS

  9. USE-CASE SCENARIOS

  10. Add course • SYSTEM: display home screen • USER: select “add” • SYSTEM: display “Add screen” • USER: select “course” • SYSTEM: ask for course name and info • USER: input all the requested info • SYSTEM: show inputted info, save? • USER: select save or not • SYSTEM: save event or discardinput • SYSTEM: show results USE-CASE SCENARIOS

  11. Add course Edit Event • SYSTEM: display home screen • USER: select “add” • SYSTEM: display “Add screen” • USER: select “course” • SYSTEM: ask for course name and info • USER: input all the requested info • SYSTEM: show inputted info, save? • USER: select save or not • SYSTEM: save event or discardinput • SYSTEM: show results SYSTEM: display home screen USER: select “show events” SYSTEM: list events USER: select one SYSTEM: show a dialog box with previous information USER: change the previous information and confirm SYSTEM: alter the previous information, confirm the alteration and back to home screen USE-CASE SCENARIOS

  12. February 2014 • Original Project Proposal • March 2014 • 1st week | Domain Analysis Stage • 2nd week |Project Requirements Analysis • 3rd week |Project Requirements Analysis • 4th week | Design Stage • April 2014 • Development Stage • May 2014 • Testing and Validating • Project Delivery Date • May 6th 2014 PROJECT SCHEDULE

  13. Four Categories • Functional Requirements • Quality Requirements • Platform Requirements • Process Requirements REQUIREMENTS

  14. First Category • Functional Requirements • Quality Requirements • Platform Requirements • Process Requirements REQUIREMENTS

  15. FUNCTIONAL REQUIREMENTS • F1. The application should allow the following functionalities for Events: • F1.1­  Add • F1.2­  Delete • F1.3­  Edit • OBS: Events can be homework, community service, class meeting,  etc. • F2. The application should allow the following functionalities for Courses • F2.1 Create • F2.2 Delete • F2.3 Assign Event

  16. FUNCTIONAL REQUIREMENTS • F3. Set reminders for Events • F4. Display reminders on Android’s main notification bar • F5. Display upcoming events and enrolled courses onanorganizedhomescreen

  17. Second Category • FunctionalRequirements • Quality Requirements • Platform Requirements • Process Requirements REQUIREMENTS

  18. QUALITY REQUIREMENTS: • This application should take no more than five seconds when  processing input from the user. RESPONSE TIME

  19. QUALITY REQUIREMENTS: • The maximum amount of memory that this application should  consume is no more than 30MB. RESOURCE USAGE

  20. QUALITY REQUIREMENTS: • We aim for this program to have a maximum of one failure in a week long period ofcontinuous usage. RELIABILITY

  21. QUALITY REQUIREMENTS: • At any given down time, the program should not be functionless for more than one minute. AVAILABILITY

  22. QUALITY REQUIREMENTS: • Should the application crash, the program will be rebooted by android  and the data will remain intact. RECOVERY FROM FAILURE

  23. QUALITY REQUIREMENTS: • This program should allow for future enhancements such as cloud  storage so that the application can send and receive data on multiple devices MAINTENANCE

  24. QUALITY REQUIREMENTS: • This application should be very intuitive. Any person that know to use Android systems can use it. USABILITY

  25. QUALITY REQUIREMENTS: • About 40% of the code used to create this application should be  specifically designed so that it can be re­used. REUSABILITY

  26. QUALITY REQUIREMENTS: • As a local application, this program should have personal control about  data. SECURITY

  27. Third Category • FunctionalRequirements • Quality Requirements • Platform Requirements • Process Requirements REQUIREMENTS

  28. PLATFORM REQUIREMENTS • 1. Android powered smartphones. • 2. 2.35” by 4.18” or smaller sized, Android devices. • 3. Android devices running Android 4.0 or  later.

  29. Fourth Category • FunctionalRequirements • Quality Requirements • Platform Requirements • Process Requirements REQUIREMENTS

  30. PROCESS REQUIREMENTS • 1. Entire application will be written in the bundled Eclipse with  the Android Software Development Kit • 2. All source code must be commented sufficiently • 3. All source code must be reviewed by all members of the team • 4. Cost: this project proudly takes full advantage of the free,  open­ source software available to us from the good folksat the Open Source Initiative (www.opensource.org) • 5. Delivery Date: first week of May, 2014.

  31. February 2014 • Original Project Proposal • March 2014 • 1st week | Domain Analysis Stage • 2nd week |Project Requirements Analysis • 3rd week |Project Requirements Analysis • 4th week | Design Stage • April 2014 • Development Stage • May 2014 • Testing and Validating • Project Delivery Date • May 6th 2014 PROJECT SCHEDULE

  32. UML DIAGRAM

  33. February 2014 • Original Project Proposal • March 2014 • 1st week | Domain Analysis Stage • 2nd week |Project Requirements Analysis • 3rd week |Project Requirements Analysis • 4th week | Design Stage • April 2014 • Development Stage • May 2014 • Testing and Validating • Project Delivery Date • May 6th 2014 PROJECT SCHEDULE

  34. Proposed Gantt Chart

  35. Reformed Gantt Chart

  36. February 2014 • Original Project Proposal • March 2014 • 1st week | Domain Analysis Stage • 2nd week |Project Requirements Analysis • 3rd week |Project Requirements Analysis • 4th week | Design Stage • April 2014 • Development Stage • May 2014 • Testing and Validating • Project Delivery Date • May 6th 2014 PROJECT SCHEDULE

  37. Screen Shots

  38. Screen Shots

  39. Screen Shots

  40. APP INFO

  41. The Just delightful Planner LIVE DEMO .. We will now do a live demonstration of our fabulous android app..

  42. The Just delightful Planner Thanks ! Hope you enjoyed this presentation..

More Related