1. Perfecto Coffee
DCR-ARB - Team 5

2. Agenda Team Analysis (Remote Team Member)
Operational Concept Design (OCD)
Win-Win Agreements
Prototype/Product Demo
Architecture
Life Cycle Plan
Feasibility Evidence
Quality Focal Point (QFP)
Definition of Done
Metrics

3. Team Analysis

4. Team Analysis - Strengths & Weaknesses
Technical
Advanced knowledge of Computer Science as shown by admission to USC M.S. in C.S. program
Multiple students have real industry development experience
Not all team members have experience in mobile application development
Different team members have different development platforms- Mac OSX and Windows- which may result in slowdown if incompatibilities are encountered.
Operational
Frequent team communication and collaboration via Slack
Non-siloed team structure means that there is sufficient shared knowledge across project areas so nothing depends on a single person.
Two DEN students as team members means that not all members may be present during team meetings
Balancing priorities with other classes may mean that work completion occurs near the deadline and doesn’t allow adequate time for verifying quality of work.

5. Technical Concerns & Solutions
Not all team members have experience in mobile development
Solution: Select a straightforward, intuitive and accessible mobile development language/framework that allows the team to jump in and start building quickly- based on existing skill, industry consensus of difficulty, etc.
Different team members have different development platforms which may cause slowdowns if incompatibilities are encountered
Solution: Ensure that all tools chosen for development have cross-client compatibility. If not possible, make sure that all team members have access (whether borrowed laptop or VM) to an operating system that can run the tool they need.
Solution: Ensure that items that might be system-specific such as file pathnames are coded in a way that is agnostic across various systems.

6. Operational Risks & Mitigations
Two DEN students means that not all members may be present during team meetings
Mitigation: Ensure that key takeaways from meetings are summarized in Slack or communicated through to ensure that DEN students don’t miss information.
Mitigation: Work with DEN students to select a time that works with their work schedule for meetings that require attendance.
Balancing priorities for other classes may mean there are delays in work completion that doesn’t leave adequate time for testing and verification
Mitigation: Accept the risk and plan for it in advance. When estimating how long something will take to complete, encourage the team member to consider their other commitments alongside the task at hand instead of the task alone to project when something will be finished.
Mitigation: Communicate frequently to let teammates know of any obstacles or difficulties. The earlier, the better so perhaps others can step in and help.

7. Sources of Observations
Team has advanced knowledge of Computer Science
Everyone in the team was admitted to Univ. of Southern California CS Master’s program, which has rigorous admissions requirements ( that require deep CS knowledge.
Multiple students have real industry experience
Team list and LinkedIn profiles of corresponding team members. Two DEN students are currently working full-time in industry.
Not all students have experience in mobile app dev
PC-1 Risk Analysis. This was a risk that was acknowledged and mitigations were hypothesized by all team members.

8. Sources of Observations, Con’t.
Frequent team communication and collaboration through Slack
Team 5 CSSE Slack workspace and channels.
Non-siloed team structure
Throughout our last presentation (Prototype Presentation) and the ongoing work, team members have taken on different tasks across the various disciplines of our project and have not stuck rigidly to assigned roles. All teammates are also attempting to learn React Native whether or not they have development tasks.
Different students use different development platforms
We had our first challenge with different platforms for O.S. on Homework 3, where many of us Mac OS users had to go through additional setup steps to even be able to run Enterprise Architect. There exist differences for Github and similar tools as well.

9. Sources of Observations, Con’t.
Having two DEN team members may result in not all team members being present at meetings.
View Team #5 Jira and observe how meeting attendance varies based on meeting tickets per student. At least one DEN student has attended significantly fewer meetings.
Balancing priorities between may mean there is more work done towards a deadline
Through our communication in the CSSE Slack, many of our teammates have expressed life urgencies and academic hurdles that have gotten in the way of completing parts earlier. TAs can also reference our assignment submission times and dates.

10. Operational Concept Description

11. System Purpose Proposed System
The purpose of Perfecto Coffee is to expedit the coffee ordering process to save time for its customers while also giving customers the ability to craft their own unique coffee blend. By connecting its customers, Perfecto Coffee aims to foster a community through users sharing recipes via app and social media networks. With Perfecto Coffee, coffee drinkers can order high quality coffee at a lower cost, faster speed, and from more conveniently placed locations than other companies.
Proposed System
Multi-Platform application that allows users to quickly and easily order, customize, and share their coffee from their phone. Supporting this system is a server/database backend that aims to organize user, coffee, and transaction data to allow scalability for future business expansion.

12. Shared Vision

13. Benefit Chain Diagram

14. System Boundary Diagram

15. Core Capabilities

16. Constraints
CO-1: React Native as the App coding framework: The code will be developed using React, allowing the code to be used for iOS and Android.
CO-2: Close to Zero Budget: COTS API and system are to be free at least in the developing and testing phase.
CO-3: Commercial Off The Shelf Dependency: We are using Google Maps API and various social media API.
CO-4: Amazon Web Services as Database: AWS hosts our database.

17. Organizational goals
OG-1: Increase sales and profits via a more efficient customizable coffee order process
OG-2: Expand service locations nationwide and globally
OG-3: Increase user-base and foster a strong, growing, and positive community

18. Win-Win Agreements

19. Win-Win Agreements Recipe Customization
WC_4820: As a user, I can browse from a list of existing recipes.
WC_4846: As a user, I can select a coffee type (e.g. Cappuccino, Latte, Expresso, etc) and then adjust ingredients as I want from its standard recipe.
WC_4918: As a user, I can customise my coffee.
WC_4846: As a user, I can customize an existing base recipe and save it as my own recipe.
WC_4920: As a user I will be able to check if my recipe contains specific allergens
For all Win-Win Agreements, I think we should make sure to point out that some of these WCs listed aren’t going to be implemented this semester. I thought it was supposed to be the ones we agreed to implement this semester (hence that list of top 5 + UI based WCs i extracted), BUT if it includes all, then we should highlight the ones that we will be implementing vs others for later

20. Win-Win Agreements Convenience is Key
WC_4913: As a user, I can easily replace my last order.
WC_4919: As a user I can view the recipe from my saved coffee selections and choose to vend it
WC_4916: As a user, I can change which kiosk I send my order to.
WC_4917: As a user, I can use apple pay or paypal to purchase coffee.
WC_4845: As a user, I can save and set a default payment method for my orders.

21. Win-Win Agreements User Interaction Social Media Integration
Win Condition (WC_4915): As a user, I can view my order history.
Win Condition (WC_4914): As a user, I can send someone else a cup of coffee I've purchased for them.
Win Condition (WC_4899): As a user, I can earn rewards for using my coffee app
Win Condition (WC_4910): As a User, I should be able track rewards and cash in for appropriate rewards
Social Media Integration
WC_4909: As a User, I should be able to share the recipe via social media.

22. Win-Win Agreements Other main stakeholders
Win Condition (WC_4922): As a maintainer I will be able to update the location of any new kiosks
Win Condition (WC_4921): As a maintainer I will be able to track any faulty kiosks
Win Condition (WC_4912): As a supplier, I should be able to receive updates from the admin via a page on the portal
Win Condition (WC_4911): As an admin, I should have a unique portal to track inventory, view kiosk usage and track demographic information

23. Prototype/Product Demo

24. High Priority Capabilities Demo
Customization Process
Being able to customize a recipe in 3 to 4 steps.
Slider for ingredient amount adjusting.
Milk, syrup preference options.
Recipe Inventory
Show all the customized recipes.
Dependencies
Base flavor research and investigation.
Data flow and storage.
User-friendly

25. Backup Slides - Customization Steps

26. Backup Slides - Customization Steps
After going through 4 steps of customization, a review page is shown for finalizing the process.
If it is all good, by clicking “Save” button, the customized recipe is saved to users’ inventory.

27. Backup Slides - Recipe Inventory
In the recipe inventory view, users can browse all the customized recipes they have made.
By clicking each tab, the detail information of a chosen recipe is shown, users can either modify or share the recipe in this view.

28. Backup Slides - Order View
In the order view, users can either choose to vend a existed base recipe or a customized flavor from their recipe inventory.
By clicking the tab at the bottom, a map view is shown letting users to pick a preferred kiosk for vending the order.

29. Backup Slides- Kiosk Search View
In the kiosk search view, users can see their location information and information of kiosk.
By searching the address on the top, mapview and marker can show to users’ current location or other address.
Current location
placeAutoComplete
Usage from google apis
Provide more info to users choose the kiosk
Direction and integration

30. Architecture

31. System Context Diagram
Use AWS as server to save data.
Simple diagram
We use AWS
By using app
Service requests
Service reponses
Get the data we want

32. Artifacts & Information Diagram
Focus on Recipe Customization
Recipe have a list of data to customize.
In home page,there is two main parts
As we can see in the demo if we want to Add sugar or milk
And we add data into the list
Then we can achieve the share and order
Once we finish customization, then we can put this recipe as order or share to others.

33. Use Case Diagram Most important use case: Recipe Customization
After login successfully, it will get the recipe list for users to customize.
As the customization is our most important and basic function We use this as our use case diagram

34. Hardware Component Class Diagram
Customer: Mobile Devices
Supplier: Kiosk
Database: Json
Back-end Server: AWS
Client side: Kiosk and mobile devices
We use AWS to save our data beside we also get the data we want from third party libraries

35. Software Component Class Diagram
Mobile app: 6 main pages
Database: 4 Json files
Third party libraries: 2
To achieve our functions, we design 6 main pages.
For data, we design 4 json files for developers can get and add data easily and organizedly.
We also use two third party libraries to get the data we need

36. Life Cycle Plan

37. Life Cycle Plan Purpose:
To plan and document the life-cycle through all phases of the Perfecto Coffee App
Strategy:
NDI/NCS team
Assumptions
Project will be carried out over 12 weeks with the team of 6 on campus and 2 off campus students up to app completion
Phase by phase documented plan with targets and schedule
Non Developmental Item/ Network Centric Services team
1 semester long, 8 students and a client. Considering until app software is developed

38. Life Cycle Plan - Strategy
Identify activities and project deliverables through all phases
Define key stakeholder responsibilities by phase
Outline project tools
Mechanisms for monitoring, feedback and coordination
Ensure the project remains on schedule using cost estimation
Activities milestones and deliverables for
Stakeholder responsibilities
Project tools and software (read in LCP report)
Project plans and reviews and reports
Cost estimation using COCOMO II

39. Life Cycle Plan - Foundations Phase
09/28/18- 10/22/18
Activities:
Risk mitigation strategies developed and documented
Further develop prototype for highest risk use cases
Cost estimates formulated
Deliverables
Front end UI using React Native
Customisation UI
Social media API integration
Google Maps API integration
Back end database
DC package and DCR-ARB
Technical debt report
Improved prototype using React Native instead of XCode
Cost estimate created with COCOMO II
UI with customisation page with social media and maps integration
Database created
DC package documentation and presentation
Possibly cut slide if too long

40. Life Cycle Plan - Development Phase
10/22/18- 11/30/18
Activities:
Increase functionality by implementing new use cases:
Save recipe
Payment
Order history
Consult client with each development increment to realign goals based on progress
Test code after implementation
Review documentation changes alongside implementations e.g. update cost estimation
Phase starting next week
More use cases: saving recipes, payment and order history.
Depending on progress, we can redefine end point adjusting project plan (add in more use cases, e.g. scheduling)
Ensure client is involved in decision making process in what to develop
Code testing to ensure robust and without defects
Update documentation alongside new features and use case development

41. Life Cycle Plan - Development Phase
10/22/18- 11/30/18
Deliverables
Core capability drive through report
Transition readiness review
Project archive
Core capability drive through
Transition readiness report, in our case readiness to transition to hardware integration development
Project archive containing all documentation

42. Life Cycle Plan - Operation Phase
Undetermined/ Dependent on Hardware Development
Activities:
Product service
Maintainer duties
Track problems (App and kiosk related)
Utilise admin portal to track ingredients stock and supply
Expand service (more kiosks)
Deliverables
Maintainer reports
Operation depends on kiosk development
During service maintainers have responsibilities (Problems - bugs with app, problems with kiosk)
Admin portal has to be updated so kiosks can be stocked before they run out and supplies can be tracked
Update new kiosk locations
Maintainers will produce reports during service

43. Life Cycle Plan - Key Stakeholder Responsibilities
Bruce Long - Client
Jaimin Patel - Project Manager/ Life Cycle Planner
Edward Hays - Requirements Engineer
Yucheng Hsieh - Software Architect
Atreya Lahiri - Feasibility Analyst
Yun Shen (Flora) - Prototyper
Andrew Tran - Operational Concept Engineer
Chloe Good - IV & V/ Quality Focal Point
Yekaterina Glazko (Kate) - IV & V
Bruce - Analyse proposed system and identify objectives
Jaimin - Project plan and progress tracking. Develop and document plan, resource estimation.
Eddie - Define system and software requirements
Yucheng - Evaluate system components (NDI/NCS), define architecture
Atreya - Come up with risk mitigation strategy, analyse NDI/NCS interoperability
Flora - Develop prototype and iterate
Andrew - Identify objectives and constraints
Chloe - Come up with quality management strategy
Kate - Verify validate and ensure robust development, work with defects.

44. Life Cycle Plan - COCOMO II Scale Drivers
Value
Rationale
Precedentedness
Nominal
Mobile apps for customising coffee exist: Starbucks and Costa Coffee (not vending). React Native is mostly new to developers.
Flexibility
High
The final product is flexible as we are consistently reassessing based on completed work and projections.
Risk Resolution
Low
Some unavoidable risks: There is architecture risk when integrating with the kiosk hardware when it is developed could be a significant problem.
Team Cohesion
Each team member has delegated roles and responsibilities, meetings are held multiple times per week and Slack is used effectively.
Process Maturity
The process follows capability maturity model guidelines.
Precedentedness - Starbucks and Costa have same customisation functionality except Barista. Developers have not used React Native
Flexibility - End point is constantly changing
Risk resolution - Hardware/software integration may be problematic, mostly unavoidable
Team cohesion - A lot of contact with on campus members, off campus members are kept updated
Process Maturity - Follow guidelines of Capablity Maturity Model

45. Life Cycle Plan - COCOMO II Cost Drivers
UI Module
Database Module
Sharing Module
UI is a complex module, many features to integrate to this: high
Database Module - Using AWS MySQL, not likely to change so Platform volatility: low
If sharing module fails, will not result in catastrophic failure so: low

46. Life Cycle Plan - COCOMO II

47. Life Cycle Plan - COCOMO II Resource Estimation
Total SLOC: 2250
Effort:
Over semester: 18hrs/week x 8 members x 12 weeks = 1728 hrs
Monthly: 18hrs/week x 8 members x 4 weeks = 576 hrs
Estimate effort (Most Likely) = 8.2 person months
Required time
Time required: 8.2 person month x 152 hrs/person month / 576 hrs/month = 2.17 months
Conclusion
The project can be completed within the allocated time of 12 weeks
Work 18 hours per week with 8 members.
From COCOMO II using 8.2 as the most likely effort in person months
2.17 months is less than semester so project can be completed :)

48. Feasibility Evidence

49. NDI/NCS Integration NDI/NCS Purpose React Native
Primary platform for app development
AWS
Communication between for React Native and MySQL
MySQL
Store bulk data required for app
Facebook API
Enhance user experience by communicating with others
Google Maps API
Allow for tracking Kiosk Locations

50. Business Case Costs Initial Setup Cost Supplier fees Server fees
Scaling costs
Benefits
Cheaper, high quality coffee
Location friendly
Flexible ordering process

51. Risk Analysis Risk Description P(L) 1-10 S(L) RE
Hardware integration with kiosks - uncertainty concerning hardware and hardware specifications 10 8 80
Platform for App Development - Uncertainty over future direction in terms of available platforms and their capabilities 5 9 45
Intuitive graphical design - user experience is dependent on the intuitiveness of our UI 6 36
Database reliability - uncertainty concerning security of database 2 20
Payment system / authorization

52. Software & Hardware Costs
Type
Cost
Rationale
Server & DB Hosting
$240/Yr
This is low level AWS hosting after the first free tier year. Necessary for the app the run and allows for expansion if the app grows.
Facebook API
Free
At the current stage (for login and sharing), additional cost are not required. In the future, if access to insights is desired, costs will apply.
Google Maps API
1,000 Loads daily, upto 150,000 with ID verification. Additional loads require custom premium plan.
Necessary for the app to access various kiosk locations across the state of CA

53. Personnel Costs Activity Hours/Person UI Prototyping 5
Use Case Analysis 3
Win Win Sessions 2
Client Meetings

54. Persona #1: “Mark the Engineering Grad Student”
Attributes
Very busy student focused on advanced classes, homework, and their part-time research job in the lab.
Relies heavily on coffee to get through the day- and sometimes even the night.
Somewhat health-conscious; is focused on eating and drinking healthier stuff because they’re still trying to lose their freshman 15 while living a sedentary student lifestyle.
Goals
They want to be able to easily attain coffee at any time of day or night- preferably as quickly as possible- so that they can stay alert between classes and work.
They want to pick up a coffee that’s close to them- wherever they are.
They want to be healthy and consume food and drinks that don’t interfere with that.
Behaviors that relate to our product
They use online ordering such as Starbucks Mobile order so that they don’t waste time in line at the Starbucks between classes and chance being late to class- and frequent different locations depending on which is closest.
They customize their drinks based on the occasion- an all-nighter could call for a double espresso while a casual morning flipping through a textbook at a table in a quad could call for a warm, gentle latte experimenting with different flavours.
To help them, we SHOULD:
Be available for them 24/7. They could need coffee at any time of the day.
Make it quick and easy to find a kiosk near them whether they’re at the dorm or the lab.
Allow them to make healthy choices for their health needs such as choosing amount of sugar, fat in milk, etc.
To help them, we SHOULD NOT:
Not be available at times when they need us most. They should be able to order on a late morning or in the middle of an all-nighter.
Make it difficult to find a kiosk close to them. Their location changes a lot throughout the day.
Only have limited recipe options that may have high levels of sugar or fat.

55. Persona #2: “Shreya the Rising Marketing Manager”
Attributes
She wakes up with a 5 a.m. Soul Cycle class then drives her Tesla 3 to her polished corporate office for her 8 a.m. briefing with the executive team and then is packed with meetings for the rest of the day.
Drinks a cappuccino in the morning and in the afternoon because she likes how it makes her feel sharp and ready-to-go. She only drinks cappuccinos out of habit and preference.
Is very, very health conscious. Her pristine diet is as well-managed as her client portfolio.
Goals
She has a set schedule every day and wants to do things on that schedule- she would prefer her coffee is hot and ready for her at 7:55 a.m. the moment she strolls into the office.
She wants her food to make her healthy and feel good- typically that means high quality ingredients.
Behaviors that relate to our product
Always gets her coffee (a skim cappuccino) at the same time (7:55 a.m.) at the same place (her office).
Loves to pre-plan her day; if she can order something ahead and ensure it delivers at a certain time- like her standing catering order for her team- she will.
To help them, we SHOULD:
Allow order scheduling. She knows that she wants to pick up her coffee at 7:55 a.m. every day at her office. Scheduling will ensure she gets her coffee when and where she wants.
Allow saving a recipe so that she doesn’t have to build from scratch. She gets the same cappuccino everyday so we should allow her to save and select the same recipe for quicker ordering.
To help them, we SHOULD NOT:
Be late on a scheduled order. She would be really upset if she scheduled an order to be ready at 7:55 a.m. and then she had to wait for it.
Make ordering a cumbersome process. She has no patience for repeating things to people- why would she have patience for repeating things to an app? It’s the same cappuccino- get it straight!
Have unhealthy, low quality ingredients.

56. Persona #3: “Maureen the Social Media Enthusiast”
Attributes
She spends her afternoons browsing social media between picking her younger kids up at school and dropping them off at tennis. She is really eager to see posts from her daughter in college- it makes her feel connected with her despite being far away.
Drinks coffee throughout the day. With her fellow moms in the morning, during an errand run, and while reading a book and chatting with her husband in the evenings.
Has a sweet tooth and is always eager to try the latest food trends she sees her friends and daughter post on Facebook.
Goals
She wants to get through the day- and make it a bit enjoyable. Between errands and rushing, she wants some small indulgence.
She wants to connect and relate to her daughter despite the distance.
Behaviors that relate to our product
Frequently drinks coffee in various settings throughout the day- in particular grabbing on the go when running errands. She may be in different public places for the errands.
Constantly browses her daughter’s social media feed and tries out the things her daughter recommends. Green kale smoothie with flax? Tried it. Unicorn frappe? Tried it.
To help them, we SHOULD:
Make the integration with social media a nice experience that is easy for her to understand what exactly her friend/daughter’s recipe is; ingredients, size, image, etc. so that she can determine if she wants to try it.
Allow a quick, flexible pick-up available in various locations; since her day typically has her going many different places at different times.
To help them, we SHOULD NOT:
Make it overly complicated to order someone’s recipe she admires- such as her daughter’s- at a kiosk nearby her. There shouldn’t be too many extra steps from seeing the post on social media and being able to order. She likes when apps are reliable.
Run out of ingredients on kiosks. She wouldn’t be happy if the kiosks near her were always out of the trendy chai tea mix everyone is always posting about.

57. Quality Focal Point

58. Traceability Matrix (1/3)
OCD
Requirements
Priority
Use Cases
OC-1: Recipe Customization
WC_4820, WC_4834, WC_4846, WC_4861, WC_4865, WC_4918, WC_4920
Must Have
UC-3, UC-4, UC-5, UC-6, UC-12, UC-17, UC-22, UC-24
OC-2: Social Media Sharing
WC_4901, WC_4909
UC-4, UC-12, UC-13, UC-14, UC-16
OC-3: Payment Method Selection
WC_4845, WC_4917
UC-2, UC-7, UC-8
OC-4: Kiosk Selection
WC_4916
UC-2, UC-9, UC-10, UC-11
OC-5: User Profile Customization
WC_4835, WC_4845, WC_4865, WC_4898, WC_4900, WC_4902, WC_4910, WC_4913, WC_4915, WC_4919
UC-1, UC-2, UC-4, UC-5, UC-6, UC-7, UC-8, UC-9, UC-10, UC-11, UC-12, UC-17, UC-21, UC-22, UC-23, UC-24
Win condition info for each operational capability -- use case list for each Operational Capability is exhaustive - if it’s relevant at all, it’s listed
OC-1: Recipe Customization: includes selecting from a list of pre-made coffee recipes or customizing a recipe starting from a standard coffee recipe based on coffee type
OC-2: Social Media Sharing: share the recipe via social media
OC-3: Payment Method Selection: saving payment information and using as default for orders
OC-4: Kiosk Selection: allow users to search for and select a kiosk to place their order
OC-5: User Profile Customization: includes saved recipes, order history, and setting a default order (including recipe, kiosk, and payment info), ordering history information

59. Traceability Matrix (2/3)
OCD
Requirements
Priority
Use Cases
OC-6: Information & Transaction Database
WC_4820, WC_4835, WC_4846, WC_4865, WC_4913, WC_4915, WC_4919, WC_4922
Must Have
UC-1, UC-2, UC-3, UC-4, UC-5, UC-6, UC-7, UC-8, UC-9, UC-10, UC-11, UC-12, UC-16, UC-17, UC-18, UC-19, UC-20, UC-21, UC-22, UC-23, UC-24, UC-25
OC-7: Login System
WC_4909
Must Have But Not Now
UC-1
OC-8: Notification System
WC_4902, WC_4911, WC_4912
UC-2, UC-15, UC-18, UC-19, UC-21, UC-24, UC-25
OC-9: Order Scheduling
WC_4908, WC_4913, WC_4916, WC_4919
UC-15, UC-18, UC-19, UC-20, UC-25
OC-10: Inventory Management
WC_4911, WC_4912, WC_4921, WC_4922
UC-9, UC-10, UC-11
OC-6: Information & Transaction Database - tied in with user profile and recipe customization. We have to have a place to store all this information as well as manage all the different orders among the different kiosks

60. Traceability Matrix (3/3)
OCD
Requirements
Priority
Use Cases
OC-11: Recipe Gifting
WC_4844, WC_4909
Must Have But Not Now
UC-4, UC-13, UC-14, UC-16
OC-12: Recipe Reviews
WC_4820
UC-4, UC-12, UC-16
OC-13: Rewards System
WC_4899, WC_4910
UC-12, UC-13, UC-14, UC-16

61. Quality Management Strategy: Defect Prevention
Priority
Level
Description
Win-Win Negotiation
High
Client & Team
The team worked with the client to establish a set of viable win conditions and to identify the highest priority items to implement for this iteration of the app.
Benchmarking
Medium
Team
The team researched the UI and standard functionalities of similar coffee/food ordering mobile applications.
Version Control
Github will be used to manage and track project source code changes.
Continuous Progress
Monitoring & Tracking
Project progress is being monitored/tracked through Jira tickets and through shared Google Drive document monitoring.
Frequent Team
Communication & Collaboration
The team has weekly team meetings as well as regular communication and collaboration through the team’s Slack workspace.
Peer Review
Team members review deliverable documents (e.g. project assignments) and project app code (i.e. GIT repo) and provide feedback and/or suggestions as necessary.
Win-Win Negotiation - discussed what we can do as software engineers (i.e. we can make a mobile app)
Benchmarking - look at Starbucks app helps with UI design and identifying the basic functionalities required to order coffee
Version Control through Github - track and manage code changes
Progress monitoring/tracking through Jira (Create tasks, track defects) and shared Google docs
Team communication via Slack and team meetings
Peer Review of required project documents and code review

62. Review Identification Method Test Identification Method
Defect Detection
Review Identification Method
Description
Peer Review
Team members review deliverable documents and project app code and provide feedback and/or suggestions as applicable.
Instructional Staff Feedback
Instructor feedback/suggestions based on project presentations, team discussions with instructional staff, and Piazza posts.
Client Feedback
Client feedback/suggestions based on Win-Win negotiations, project presentations, and team-client meetings.
Test Identification Method
Description
Unit Test
Each commit to the GIT repository will be pulled, tested, and verified by IIV&V team members (at a minimum) based on each commit’s functional change description, and bug reports will be generated as applicable.
Integration Test
Each commit to the GIT repository will be tested against both commit-related test cases and previously passed test cases to verify that the changes have not affected existing app functionality.
End-to-End Test
True end-to-end testing would involve hardware integration. Since we lack hardware, test and verify that all implemented functionalities work and that the associated database information is populated/updated/removed as expected.
Various review methods - internal peer reviews, feedback from professors (presentation and Piazza) and client (win-wins and other meetings)
Test methods - Unit test of each capability and all involved use cases
Integration testing to verify that the capabilities work together without any negative side effects
End-to-end would require app and kiosk integration which we can’t do for now, but we can verify front-end to back-end functionality in terms of verifying that user interaction (orders, recipe creation, etc) is correctly translated to the User, recipe, etc. database

63. Defect Tracking & Removal
Coding defects will be recorded, tracked and monitored for progress via Jira.
Process:
Developer makes a commit to the GIT repo (with Jira ID) and notifies team via the git-development channel on Slack.
Team testers (IIV&V at minimum) pull changes and test/verify functionalities of the commit.
If a tester finds a defect in a commit, he/she will create a Jira “bug” ticket, assign it to the commit’s developer, and include:
(1) a description of the issue
(2) the Jira ID/GIT commit where the defect was found
(3) the environment that was used for testing (i.e. Android, iOS, virtual/physical device).
After creating the “bug” ticket, the tester will notify the developer and/or the team of the finding via the git-development channel on Slack.
When the defect is resolved, the assigned developer commits the fix to the GIT repo (with “bug” ticket ID) and closes out the ticket.
Since we are using React Native for our app development, we will test and verify the app with both iOS and Android. However, our main focus of the mobile application is iOS development. If we learn that certain features/bugs are only found in one of the two, a note will be added to the “bug” ticket, but the priority will be on fixing iOS bugs.

64. Current Defect Injection & Removal Matrix
Defect/Concern
Type
Proposed Solution
Late start on app development due to transition from iOS-based prototype to React Native framework
Avoidable Defect
Research tutorials and documentation on how to develop with React Native (e.g. how to integrate social media APIs, Google Maps API or alternates, AWS etc).
Accuracy regarding base recipes of coffee types in the app’s recipe database.
Research basic coffee recipes online (e.g. Mr Coffee Barista standard recipes) and cross reference other coffee sellers (e.g. Starbucks).
Possible conflicts between kiosk and mobile app options
Unavoidable Defect
Study the hardware specifications of the kiosks described in the original project proposal. Assuming that the app will eventually need to integrate with hardware with similar specs, implement our customization feature and database objects with these specs in mind.
Need to ensure the robustness of the User, Order, Recipe, and Kiosk DB objects include all the parameters required to satisfy all operational capabilities.
Concern
Revisit the DB prototype structures and cross-analyze them with the win conditions, use cases, and operational capabilities in order to form a comprehensive list of each object type’s necessary components.

65. Technical Debt (1/2)
Description
Type
Mitigation Plan
Team inexperience with React Native. In order to enable our mobile app to work for both iOS and Android, we have proceeded with using React Native for app development.
Personnel Shortfalls
The team has been researching and training with various React Native development tutorials and documentation available on the internet.
Inability to test app/hardware integration due to hardware unavailability. The kiosk hardware (as well as hardware specifications) that will be needed to integrate with the app does not currently exist. Furthermore, the hardware specs will also impact the app's customization feature and other processing, so once hardware is available, the app customization functionality may need to be updated.
Methods, Processes and Tools (MPT) Shortfalls
The team can research existing machines’ hardware specs (e.g. measurement units for different flavors) and implement the customization feature and DB structures according to those specs since they will likely be similar to the future kiosk’s specs.
Possible discrepancy between available customization options (i.e. the different syrups, milk types, etc available at each kiosk) vs the flavors the client/customers want.
Whether we can actually replace/change flavors will be hardware dependent. However, in the app, we can add a "Customer feedback" option on the app and/or add the option to suggest other flavors (e.g. a "Not seeing the flavor you want? Let us know" button) via the "Customization" page.
Tech Debt -- DEFINITION: reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longe

66. Technical Debt (2/2) Description Type Mitigation Plan
Limited login capability. To minimize security issues in initial development, app login will be restricted to Facebook login for the initial app.
Personnel Shortfalls
Once the core application features and capabilities are complete, the team can investigate how to include an app-only user sign-up feature with all the required security protocols to protect user information.
All recipes will be public until the basic customization feature is complete
We will have a isPublic flag included as a part of the Recipe DB object so once we verify our core customization capability, we will be able to explore how to manage recipes are private vs public.

67. Definition of Done
Implement, test, and verify mobile application (focused on iOS app) for all agreed-upon win-win conditions/requirements for the 1st semester product release.
Since the team is using React Native to create the app, we are performing testing and verification on both iOS and Android. However, the team’s main focus is to create an iOS app. So, if a defect is found that is Android-specific, it may not be fixed in time for the end of the semester. In this case, a defect log of Android-only anomalies will be maintained and submitted.
Provide detailed documentation of all the completed requirements (e.g. DC package) as well as provide a list of all the incomplete requirements that would need to be implemented in later releases, including a path forward for each. Documentation includes:
Test plans (performed on both iOS and Android) with corresponding PASS (and hopefully no FAIL) information and other artifacts as applicable.
User manual
Complete a full code review of the product (with artifacts from the review as applicable)
Make source code available on server for course instructors and client.
Demo final product with the client to verify that the product meets and/or exceeds expectations.

68. Metrics
Defect Monitoring (including tracking of Android/iOS specific defect)
Objective: Monitor and track coding bugs and/or enhancements (for both iOS and Android, but with an iOS focus) throughout the app development process.
Benefits: This allows us not only provide a timeline until completion but also aids in pinpointing when the bug is created through each version update (enhancement).
Progression Monitoring vs Estimated Time
Objective: Monitor progress of issues to compare amount of time spent on the issue against estimated time
Benefits: This allows us to see which issues are potentially going to use up more time, giving us the options of allocating more resources to finish in time and re-evaluating the issue to mitigate future problems.
Demo Performance
Objective: Monitor the usage of resources (memory, battery, network usage) by the application as the code changes every time it is tested on various phone models
Benefits: Different from defect monitoring, this gives us numbers that can be correlated to the availability of the application on deployment based on market-ready phone model capabilities and our app’s resource usage.
IMPORTANT: we are expected to collect these 3 metrics after the presentation, and we are suppose to set an amount of time we will gather the info (e.g. biweekly, etc)
Example of Metrics from slides
•Progress / Effort / Cost Indicator
•Earned value management
•Requirements / Code Churn
•Defect-related metrics
•Test-related metrics
•System-related metrics
Examples we have given through paper: I dont think we took a picture. Might as well start listing them here and choose the simplest ones to answer.
-risk amount and duration
-client would want to see costs of project vs time maybe?
-client definitely wants to see supply and demand per location
-but the previous metric is for the end. The first client metric i mention is cost of project vs time. -

69. Q & A