1 / 21

Project 40: Call For Code

Project 40: Call For Code. Austin Keen, Caleb Nash, Justin Kaufer, David Boschwitz, Logan Fladung, and Robert Schedler Advisors: Diane Rover and Nicholas Fila Client: IBM Call For Code Competition. Task Responsibility/Contributions. Austin Keen Graphic Design Lead. Logan Fladung

Download Presentation

Project 40: Call For Code

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. Project 40: Call For Code Austin Keen, Caleb Nash, Justin Kaufer, David Boschwitz, Logan Fladung, and Robert Schedler Advisors: Diane Rover and Nicholas Fila Client: IBM Call For Code Competition

  2. Task Responsibility/Contributions Austin Keen Graphic Design Lead Logan Fladung Subject Matter Expert David Boschwitz Team Lead Robert Schedler Lead Backend Caleb Nash Lead Frontend Justin Kaufer User Research & Test Lead

  3. Problem Statement Goal How? Problem With natural disasters becoming increasingly more common, ways to provide relief to these victims are becoming more and more necessary The goal of Call for Code is to design a tool to improve preparedness for natural disasters and relief to safeguard the health and wellbeing of communities in disaster stricken areas By leveraging tools such as Xamarin, Ad Hoc networks, NUnit, and various API’s, our team hopes to create an easily accessible and easy-to-use solution

  4. Functional Decomposition Call for Code User Research Testing Development Interviews and Research Maps, News, Messaging, etc. Unit Tests User Requirements UI / UX Integration Tests Technical Requirements Backend Integration Usability Testing

  5. Functional Requirements Mark roads that are unsafe and not allow routes through them Track users and reroute paths based on traffic along popular routes Work across iOS and Android platforms Allow users to send emergency pings to relief workers Provide users with locations of relief support

  6. Functional Requirements cont. Allow users to communicate with each other via chat messaging Function without internet and cellular connections through an ad hoc network process Have different types of users including relief worker, ordinary user, and admin Provide constant news updates based off local settings

  7. Non-functional Requirements Overview Performance Scalability Accessibility Security • Ability to maintain performance and operation from not only concentrated local areas but to more distributed geographic regions • Ability to add new features and deploy rapidly • Ease of usability, the interface is easy to learn and navigate • Application should work with or without network connectivity • It is important that users experience short response time, within 3 seconds from their request • High availability of our system with above 99% uptime • Secure sign-in of authenticated users cannot be duped. • 100% of messages will be encrypted

  8. Conceptual Sketch

  9. Technical Considerations • Android market share is approaching 90%as developing countries are getting cell phones. • Increased focus on Android devices. • Xamarin library works with both AndroidAnd iOS and would approach 100% of Market share. • Allows for implementation to iOS in future.

  10. Market Survey What makes our project unique? • Looked at other emergency applications • Shows up to date information for: • Road closures • Red Cross locations • Supplies • None utilized ad hoc networks • Allows for use of application even if there is no cellular or data coverage • Allows for spread of critical information between devices

  11. Potential Risks & Mitigation Risk Mitigation 03 02 01 • Certificate chain • Use private-public keys • Potentially include dual-approval system updates • Verify identity of admin users Similarly with chat functions and bad users Could spread misinformation Admin system hijacked by hackers

  12. Resource/Cost Estimate • There is little cost involved in our project • Mobile application • Red Cross and Law Enforcement are admin users • Software is low-cost and not-for-profit • Costs in future could include maintaining servers • Relatively low cost • Designed to not need a lot of infrastructure

  13. Project Milestones & Schedule Research: Complete User Stories: Complete Software Requirements: Complete Project Plan: Complete Development: Initiated Testing: Tabled for 2nd Semester

  14. Detailed Design

  15. HW/SW/Technology Platforms Used • Android or iOS devices. • Xamarian library • C# • Autofac dependency injection • .NET Standard • SQLite for database • Google maps API • NUnit

  16. Test Plan Unit Integration Usability • NUnit • Arrange, Act, Assert • Hybrid of Test Driven Development • E.g. creating a new user and checking that it’s stored in the database, as well as correct information • Interactions between components • Xamarin.UITest • Automated UI testing • REPL • E.g. navigation to the news feed from the main menu • User demographic survey • Tasks established by feature team • Feedback from users • Redesign / validate feature usability https://youtu.be/SsU8vg1_g0s?t=578

  17. Dependency Injection (Autofac) Basic Building Block Implementations Abstraction • Reduce coupling of concrete types from code that utilizes that type • Injects the rules of interface into the instance • Mock components for simulation • Hiding unnecessary details by using interfaces • Simplifying to input and output information • Interface rules validate that the components work

  18. Implementation Diagram (Status, Challenges) Challenges • Cross-Platform Compatibility • Learning Frameworks Status • Main mobile application is functional • Backend needs further development

  19. Current Project Status BEHIND SCHEDULE • Did not start development as stated in initial project plan • User research is more important for a humanitarian project SUCCESS/IN PROGRESS • Completed several prototypes using technologies that we plan to use • Verified our chosen technologies will work as we thought Core Development Overall User Research Prototyping ON TRACK After a successful semester of extensive research we are excited to take what we have learned and begin development SUCCESS • Supervised by Dr. Nick Fila • Created User Stories based on News Reports • Dove deep into creating requirements based on user stories • Proved user stories by conducting user interviews

  20. Plan For Next Semester Continue User Research Continue Prototyping New Technologies Begin Component Development Quality Assurance & Testing Finalize App

  21. Questions?

More Related