430 likes | 448 Views
This Transition Readiness Review (TRR) outlines the operational concept, objectives, and strategy for the transition of Perfecto Coffee's mobile app. It includes a product status demo, test cases and results, and a transition plan summary.
E N D
Perfecto Coffee: Transition Readiness Review Team 5
Agenda • Operational Concept Overview • Transition Readiness Review (TRR) Specific Outline • Transition Objective & Strategy • Product Status Demo • Test Cases - Procedures & Results • QFP • Transition Plan - Summary
Operational ConceptOverview • Expedite the coffee ordering process • Customizability of coffee • Availability of coffee • Build a community through social media • This is still the goal, with us working with user experience as our guide • The standard app model for coffee customization and ordering is Starbucks • What we had before was an attempt to make a new app without trying to copy • After the core capability drive-through session, concept direction changed to incorporate applicable features from the Starbucks app
TRR specific outline • Finish core features for highest priority use cases of the current mobile app • Provide documentation for the transition of the created software for new developers to continue development • Outlining a plan for future iterations of the app • Hand over the app to the client for further development and testing
Transition Objective & Strategy Objectives for the next development iteration: • Provide future direction and considerations for development • Provide proper information required to setup the environment to continue development Strategy for Transition: • Overall, this is an incremental transitioning in terms of development • During the kiosk development and testing, it will be parallel operations
Backend Demo Running on Node.js and Sails.js Database has been restructured to allow future flexibility Some new features • Stripe • Mailgun • Revamped User Table • Ingredients Table • Admin Login
Testing Overview • Focusing primarily on testing of key functionality rather than creating a rigid automation structure due to constantly evolving software development. • Tested primarily for iOS via XCode simulators • Some testing done via Android Emulator but most functionality is currently working on iOS
Testing Procedures iOS • Running a simulator via XCode Automated • Not fully functional yet but for repetitive UI testing Manual • Testing functionality like an actual user would Android • Running an emulator through Android Studio Cadence • Weekly or given a new exciting functionality or update
Testing Considerations • Is the app broken or is your setup broken? • Testing through Android and iOS simulators creates plenty of opportunities for errors due to poor backwards compatibility of XCode and related tools. • Some people are limited by resources (PC or Mac) or existing software versions (OSX Sierra vs OSX Mojave) which complicates testing. • Even one SDK (Facebook SDK) or tool (React) being a version behind can throw warnings, not errors, but actually prevent your app from executing correctly. For future testing, we will document the exact details of the system on which the application can run without error including: OSX version, XCode version, React version, Node version, React Native version, Facebook SDK version, etc. so less time is spent debugging setup.
Test Results Total: 23 test cases
Transition Plan - Summary • Hardware/Software/Site/Staff Preparation • Operational testing, training & evaluation • Stakeholder roles & responsibilities • Milestone plan • Software product elements & required resources
Hardware/Software/Site/Staff Preparation • Hardware • Kiosk should be prototyped by hardware developers • COTS components and hardware-component integration • Software • Packaging of developer code for each module • As all software is free, it is readily downloadable • Installation steps used from the technical manual for further development/testing • Site • Client must select new site for software development, remote/on-site development • Client must select site for hardware development dependent on location of hardware developer team • Staff • Staff require training for development
Operational testing, training, & evaluation • Testing • Throughout development process, we have been unit testing to ensure the functioning of the code • Test cases outlined by Kate • Training • Future developers will train themselves using the tools provided in the technical manual (GitHub instructions, database, servers, administration, front-end, API integrations) • Users and testers will train themselves using the app itself and the user manual • Evaluation • Ensuring the client’s expectations are met to proceed with development • Gathering and considering the metrics collected for the development phase
Stakeholder Roles & Responsibilities • Current • Software Team: Provide documentation and release current software to the client for new developers • Client: Give project direction and find new developer teams • Post-Transition • Hardware Team: Begin work on kiosk development • Software Team: Assess interoperability of designed software to hardware components • Investors: Capital for hardware/software development • Client: Outline specification for kiosk requirements to hardware developers, plan future business/employee location, find ingredient suppliers and maintainers
Milestone plan CCD Session 16th Nov TRR Presentation 30th Nov Handover 5th Dec
Software Product Elements &Required Resources • Code • Front-end UI source code written in JavaScript using React Native for iOS • Back-end database hosted by AWS written in MySQL using Sails.js • Admin Portal website • COTS services: Software support resources can be found in the support plan • AWS & Sails.js • Google Maps API • Facebook API • Documentation • App installation procedure and software tool documentation found in technical manual • As-built package documentation in project archive: OCD, FED, SSAD, LCP, TPC, TP, UM, SP, TM