p Sahoja

Key Points


References

Reference_description_with_linked_URLs_______________________Notes______________________________________________________________
https://drive.google.com/open?id=1qWiAcLninGKDSvvusDOmRMPEu-noZpA2Sahoja folder
https://drive.google.com/open?id=17aDw-etu4lgUAO-l0yPcOdBesrEiKvdiSahoja Requirements
https://app.smartsheet.com/sheets/Vw5JH3hc7CXRCCHjr267W8PF67cCF4gCVQRJRP61?view=ganttSahoja WBS
https://drive.google.com/open?id=1T_6E0vu1y_OyM_karC9mqfhqr7IBlQfWpsoft Sahoja competitive analysis doc


https://drive.google.com/open?id=1to8MT5axv6shD6Xw2G3nZmrhguyXrytRMVP HL Requirements v7
https://drive.google.com/open?id=1lt-KaEHtb8qR5dWp6LkW1F4SB0giJvqGMVP Walk Through draft - v1






Sahoja Client docs
https://drive.google.com/open?id=0B9RDvFSX23w7ZnBfZklqd3BjTnlrN3hlOWJnV2pMNDJHMUxBSahoja User Journey pptx
https://drive.google.com/open?id=1-yQEEheEz5WJBow_0HAdL1tDmg1xHGYZDr Menawata Design feedback - 191209

https://projects.invisionapp.com/share/YEV59BYJWHX#/screens

https://projects.invisionapp.com/share/YEV59BYJWHX#/screens/396482665

Invision wireframes versions

Below is the Invision link from today’s call.

https://invis.io/YEV59BYJWHX


https://sahoja.atlassian.net/secure/RapidBoard.jspa?rapidView=1&view=planning&selectedIssue=SAH-74&issueLimit=100Sahoja Jira query
https://docs.google.com/spreadsheets/d/184PS7J5_25WtWWqZD4Bv_5g4Dzhs8lR9/edit#gid=422326398Sahoja milestones doc


References, articles


https://bitscreener.com/news/zealeum-the-blockchain-based-health-and-wellness-platform-announces-its-pre-saleZealeum wellness site and tokens
https://steem.ioSteem site for social good


Sahoja Tokens
https://docs.google.com/spreadsheets/d/1s5-I_kmBe-JuI_v-0gyTUS1cCZXopOWcaJPL1puO3dY/edit#gid=1930725849Token transaction matrix design
https://docs.google.com/spreadsheets/d/1s5-I_kmBe-JuI_v-0gyTUS1cCZXopOWcaJPL1puO3dY/edit#gid=391203623Token economics for Sahoja
https://drive.google.com/open?id=1fKQDR-YxUOG5s_jX4rJ5w8oS1ewZ-lUWSahoja tokenisation



























Key Issues

issue_________owner_________status____action_______description_____________________________________________________
product charter


mission, vision, community, features, scope, environments, support, resources
product definition


product definition with release roadmap  - VCRS

factur3.io

stakeholder map


stakeholder RACI map
application strategy


phases > deliverables

business model > app models > api models > data models

architecture strategy


functional, non-functional requirements summary

architecture design choices:   TDD ( BPM ), UX, API, resources, data

risk issues log



engineering log


engineering decision log
release roadmaps


targeted features
use case map


use cases and actors
BPM


business process model for use cases
GAPS


plan document followed by WBS in gsheet
OARS


weekly reporting on the current release program


















Key Concepts


Sahoja Roles

users, influencers, partners, Sahoja, vendors, auditor



Sahoja MVP

web

react

linux

mongodb

azure functions for API's    **

4 blockchain nodes - 2 zones - 1 org

token exchange via Stellar network

smart contracts for users, impact partners

token mgt system

Stellar exchange system



MVP services - scrud

home page with menu

membershp enrollment management - user, influencer, groups with captcha validation

login - authentication - 2 factor - factor 2 = text or email

interests

impact projects

feeds with filters

post topics

posts - user, impact partners, Sahoja

media files

media store

post reactions - like, love, don't follow, donation

follow and un-follow user, project, topic

token management

donate to a project or donate all or donate type

user messages

session history by user by page instance by page activity

post history: views, likes


administrator functions

admin manages promotes user to impact partner membership

manage / approve / edit / delete postings

action token price master

sets user as a dashboard user



KPI Dashboard  for dashboard user

lists with filters, sorts, summary counts, detail view

users  ( no member PII info ??? names and ?? )

login stats by user-id, date, active users in a period, session length

users not logged in for a period ( week, month, 6 months, year )

activity stats by impact project, topic channel



Sahoja Release 1


full release with users, influencers, partners, vendors, payments, tokens


Planned Rollout Timeline

the rollout timeline goals don't match the development plan sequence for features ...

who thought this could work until FULL app has passed UAT ... THEN start alpha

period____goals_____________________________status________risks_______________________________________________
-6 mos

onboard 100 influencers, 10 vendors,

10 impact partners  ( alpha )

rethink

rollout by role, not count based on what can be delivered when

focus on members, partners interactions only

-3 mos

influencers invite members, 1000 members

50 vendors, 25 partners ( closed beta )


can't do this phase until full app suite done INCLUDING vendor,

partner integrations and payments!!

Day 0 betaopen beta

3 mosup to 60 partners, 120 vendors, 17K members

6 mosup to 75 partners, 140 vendors, 100K members







Project Plan Questions

Project in Smartsheet

Tasks at high level

simple card view only for scrum board / sprint mgt

q> will we use Jira plugin ? cost vs simple maint by PM for smartsheet at level 1 / 2

where are project KPIs?



Requirements questions

defer std blockchain ? sure

defer immutable ledger?  not for V1 – tokens, orders, donations for taxes etc

what does impact partner is a blockchain member mean ( not a host node I assume ) ??

what is a promotion ?? a discount on an item ??

users can message or email admin ( what about other users )?? is there a message queue to receive / manage messages?

what is the 3rd party parental control on ?? login, posts ??

should we use zendesk or open-source version for support request tracking??



Feature requirements

personal data mgt for GDPR, CCPA


Sahoja Token features

see tokenisation detail table - which are MVP ??

?? no token exchange in MVP - purchase only ??

1 point = 1 token ??

token par value = $.01 USD

earn tokens

sign up = 1000

first social post = x tokens

user activity events generate email or text

no points activity in 6 mos = nudge

no points activity in 12 mos = message a donate suggestion

no login for 12 mos = message donate all token to an impact


Rewards are tokenized and referred to as “Points”

Point values = 1 cent

Minimum transaction of 10 points

Points can be bought in batches of 10

Points never expire

“Sign-on” points cannot be cashed out

Those sending points will be charged fees (see table one)






Sahoja Token Mgt


users

  1. earn tokens on social content, from vendors
  2. spend tokens on social network, impact projects, purchases
  3. buy tokens
  4. redeem tokens




Digital Currencies

currency fees

is the currency low cost for purchases and redemptions from fiat?  exchange with other currencies? transactions in currency?


currency risk

is the currency a value transfer, a value store or a combination

only pure value transfer currencies eliminate majority of valuation risk to holders


A> Stellar examples - Stellar net, wallet, custom token



Stellar - xlm

value store and value transfer

stellar lost 65% over the last few years ... .22 to .065

$1.3 B

The Stellar network is an open source, distributed, and community owned network used to facilitate cross-asset transfers of value. Stellar aims to help facilitate cross-asset transfer of value at a fraction of a penny while aiming to be an open financial system that gives people of all income levels access to low-cost financial services. Stellar can handle exchanges between fiat-based currencies and between cryptocurrencies. Stellar.org, the organization that supports Stellar, is centralized like XRP and meant to handle cross platform transactions and micro transactions like XRP. However, unlike Ripple, Stellar.org is non-profit and their platform itself is open source and decentralized. Through the use of its intermediary currency Lumens (XLM), a user can send any currency that they own to anyone else in a different currency.

Stellar Keys

  1. currency value risk
  2. purchase costs from USD
  3. redemption costs to USD
  4. currency exchange fees
  5. currency transaction fees


USD coin - usdc

value transfer

stable value pegged to USD

usd coin backed, stable
$.450 B
usdc
https://www.centre.io/usdc

True financial interoperability requires a price stable means of value exchange. CENTRE’s technology for fiat-backed stablecoins brings stability to crypto. The initial implementation is USD Coin (USDC), an ERC-20 token creating possibilities in payments, lending, investing, trading and trade finance — and the ecosystem will grow as other fiat currency tokens are added.


USDC Keys

  1. no currency value risk
  2. purchase costs from USD
  3. redemption costs to USD
  4. currency exchange fees
  5. currency transaction fees



Security Plan



Trust Plan



Token, Wallets Plan



CMS Plan



Partner integration plan



eCommerce Plan



Payments Plan



Vendor integration plan



MVP architecture stack





MVP design features


UX flows are where?


where are the models ??


actors

use cases

processes

event sequence models

context objects

services

libraries

frameworks




authentication model

user name and password

is there mfa using a code via call or sms?


authorization model

what framework is used ?

how are roles related to functional authorizations?

how are roles related to data authorizations?

how are authorizations managed ? as rt lookup or stored in jwt?


physical data model


why 2 user tables ( user, users ) ? what was user for? users looks valid

good use of integer, surrogate keys with autoincrement on basic entity tables

relation tables have relations as dual int keys supporting M2M relations - eg user_global_passions

thread_user links a thread and a user

thread  ( links to a comment thread table ? ) support hierarchical threads

comment table for threads layout makes sense and allows attachments

code tables ( eg passion has int pk but is not AI - why ? )

status field for entity and transaction tables in model are not found?

no version field for optimistic locking

no user id or update date for entities and transactions

events looks like an event master but no keys

event_actors is just a text name for an event actor - no entity relation?

user_tokens table is confusing – no link to tokens, what is token text ??

q> point_settings - how is this table used ?

logging - used for logging activity, links to user, no level for severity level for filtering, how populated?

event_domains makes sense – provides domain for events

q> transactions has a from and to hlfid – trans are tied to ?? not users - amount is int for non-fungible token

q> impact_partners has hlfid ... are all partners assumed to be on bc or just some or known?

q> age_ranges - why not add a sequence number for a view sort ??

q> tickets - what are user tickets used for – transactions ?? they have a status code - see ticket_statuses

projects make sense and they have goal amounts .. history of gaol changes needed ??

q> impact_partner_user - relates a user and impact partner - users can have multiple impact partner relations - is their a role?

images table is fine as is

event_actions is master table for actions

user_images relations fine

impact_partner_projects - relations table

global_passions fine

q> comment_read_status – shows when EACH user has read a comment?












Potential Value Opportunities


Sahoja User Journey Overview pptx - v1

https://drive.google.com/open?id=18sQvR7QVWH766XUOesQ0jrXWODdC4CmZ



Potential Challenges



m200127 - demo MVP v1 


Great job on the demo
Excellent job on the demo and delivery on ux and back-end services that matched the design specs from Sahoja so far.

Sahoja still in design mode
Clearly they had not gone through a deep analysis of their own design docs as a team before they submitted the design docs to Paramount. That certainly impacts rework on our end they could have avoided. The "committee" approach at Sahoja makes it difficult to finalize design requirements. Sanjeev is really the UX designer here. All others should cycle their input back to him first for review before submission to Paramount.

Project communications
Kevin is correct that we need to limit the official commnication channels for effective communications. Comments in a messaging app are not design documents to work from. Who owns the approval of design documents at Sahoja? They need to manage the inputs to Paramount and the approvals for those docs. Nice job on the Paramount end documenting our requests for input.

Engagement notifications
Sanjeev now looking to add more engagement options ( notifications to donate etc.). He should understand the need for user policies to drive that and NOT a system-wide policy on notifications. Notification options can include email or text messages.

Performance
What's the login performance trace show?

Front-end page updates on back-end transactions
2 basic options are: 1> use simple call back for page refresh or 2> web sockets updates allowing the server to push to the front-end data changes directly. Both can work well in React / Redux.

m191230 - Sahoja meetings


Monday, December 30th 2019 - Paramount/Sahoja Meeting Agendas (Draft)



1st Meeting: 10:30 AM EST to 3:00 PM EST Agenda:


  • Review/understand social media companies/business strategies/revenue models
  • UX/UI??
    • Review UX/UI Methodology
    • Review MVP UX/UI Wireframes
    • Review outstanding wireframes that need to be created
  • Review list of assignments made in the meeting
  • List issues raised to be addressed later
    • scope change?  change control ?  risk issues ?


2nd Meeting: 3:30 PM to 5:30 PM EST Agenda:


  • Quick summary of MVP/V1 timeline discussion last week
  • Requirements
    • Review High Level Requirements for V1
      • Next steps to scope out and provide estimates
      • Discuss dependencies/action items for V1 requirements
      • Discuss risks for V1
        • MVP launch and user feedback before V1 development
        • iOS and Android timing
  • Process
    • Reporting and Traceability
    • Acceptance Criteria
  • Platform
    • Discuss Stellar/3rd party



m191227 - John Bonaccio Meeting Notes


Here are my notes from the subject meeting:


  • V1 launch is scheduled for 06APR2020. Basic timeline created and team reviewed with risks identified during the meeting. Includes 6 sprints, 2 weeks each.
  • Primary concern: complexity of vendor management is riskiest part of the V1 build. How do members/vendors interact? This will drive 2 test streams (member, vendor) and will need to develop front end for both. Potential mitigation strategy is to outsource to a 3rd party “marketplace commerce” solution. Getting 100 vendors onboarded before V1 will be a challenge. Potential mitigation strategy is a “template” process based on what product/service they are selling. Also utilize partnerships to expand network.
  • Unit testing, system testing to be included in each of the sprints. Followed by 2 weeks of UAT prior to launch.
  • Another risk identified is lack of a design loop (iteration). Potential mitigation strategy is to limit the project scope for V1 launch.
  • Usability testing not included in plan. Mitigation strategy is to add 5 days before sprint 1, use external source to provide focus group testing. Kevin Carlson and Prentice Stamps will look at different options for a quick RFP from suppliers they used previously. 
  • Complexity of launching IoS, Android, and Web app concurrently will be a challenge and requires more resources, which could drive a proliferation of errors, bugs.
  • Point valuation system  and changes need to be documented.


ASSIGNMENT 1: meeting participants to individually study the timeline as it stands and

  1. Identify any missing steps
  2. Propose any adjustments to the existing worksteps
  3. Identify any risks we did not discuss
  4. Create mitigation strategies around such risks

ASSIGNMENT 2: Need to pin down the vendor management strategy in detail (John Murray, Kevin Sandlin, David Bishop with Sanjeev and Anil)

ASSIGNMENT 3: Bonaccio to review with Sanjeev

  1. Documented point valuation process
  2. Requirement for 100 vendors and 10,000 users prior to V1 launch
  3. Scope limitation of IoS vs. Android vs. web app – select one for launch vs. all three.


Timelines ???




m191223 - David Bishop's notes - Sahoja meeting


Just reiterating some points I made on the call.

REQUIREMENTS
Vendor support and the related marketplace functionality is the "longest pole" for V1 - and the greatest risk as I see it right now (for meeting our deadlines).  Design needs to start right away.  To make this happen, we need the following:
1.  Agreement on the detailed requirements for vendor functionality.  We have them from a high level perspective, but as we discussed in the call there are many details to work out.
2.  To facilitate #1 above, we should start developing some wireframes for the vendor requirements so the client can start visualizing the features - this will make #1 above happen faster.
3.  We need to decide on the marketplace solution, and how we will integrate with it.  Kevin has taken the initiative on this and narrowed it down to two, so we need him to nail this down to one and how he expects our platform to integrate with it.  This should be at the top of his action item list.  These decisions should  take priority over the code reviews he wants to do and other "monitoring" which has the potential to slow us down. 
4. V1 requirements can then be decomposed, imported into JIRA, and estimated - and perhaps v1 sprints could be planned.  This will give us a better view of where we stand. 
5. Shane and I can flesh out the API and ERD components to support vendors and other V1 features as items 1-3 are completed. 
PROCESS
Reporting and Traceability - Also, from our (Paramounts) perspective, we need to be double-dog sure that what we are delivering is in alignment with what Murray/Bonaccio are socializing in this document - that means adding user story traceability to the roadmap rollout and backlog tabs in this spreadsheet - or better yet...  Ideally, we should push JIRA as the master source of record, and perhaps pull reports from JIRA that can replace all of these ad-hoc spreadsheets that Murray/Bonaccio are creating....that way we make sure that no one can make changes that don't propagate down to JIRA and get missed.  All changes should be made in JIRA and propagate up to reporting -if possible - and/or have them sync their reports with ours if they want to maintain separate ones.  I've learned that it is always best to "Manage UP" when possible ;-)
Acceptance Criteria - as mentioned previously, this is typically done by the product manager - which is why it hasn't been completed yet - so at this point I will start filling this in.  This portion is critical to test case design and also defines the finer characteristics of the requirements.  It is also critical to minimizing "defects" which Kevin will be monitoring closely.
Other RISKS
At this time, Stellar integration is a big risk - which we didn't mention on the risk assessment call for obvious reasons.  This needs to be buttoned up as quickly as possible (which vendor we will select, how much of the solution they can help develop,etc).  Whoever we select, we need to ensure that they have experience with high volume transactions - and performing the requisite load testing.  We should keep the following in mind as we make our selection:
  • Assuming that each user could conduct on average between 5-10 point transactions daily (which I think is on the high end)
  • MVP: 1,000 users could generate 5,000-10,000 transactions daily
  • V1: 10,000 users could generate 50,000-100,000 transactions daily
Future Plans: Murray's document assumes V2, 3, etc.  If we have flexibility to move requirements into subsequent releases we need to gain an understanding of what the plan is Post-V1.  Ideally, this should become a "flow" of continuous development/improvement over time as opposed to focus on hard release dates.


m191223 - Prentice notes - Sahoja meeting

m191223-22DEC19 Sahoja Milestone v3 JBSV-1.xlsx

David Bishop and myself had a call with the Sahoja team (John Bonaccio, John Murray, Kevin Carlson) this afternoon to discuss MVP/post MVP high level planning/timelines.

Attendees:
  • John Bonaccio (JB)
  • John Murray (JM)
  • David Bishop
  • Prentice Stamps
  • Kevin Carlson
* The meeting was facilitated by John B by reviewing the timeline based on John M's spreadsheet (see attached "22DEC19 Sahoja Milestone v3 JBSV (1)"); NOTE: John B merely took what John M had originally developed and modified a few details after his discussion with Sanjeev/Anil. See the same document on drive:
initial meeting notes/comments:
* John B asked that we discuss the timeline for V1 release (April 6th) from launch date to MVP date Feb 3rd (backwards); he also wants us to commit to dates/sprints for V1 (we didn't commit to anything yet, see below)
* several of us discussed the risks of trying to develop a webapp/mobile apps in parallel for V1
* also, there are risks by onboarding vendors as there are no business process requirements for operational admin or online web portal requirements for "self administration" for Vendors, etc.
* there are a ton of new features expected (all) for V1, sure we can add resources, but that comprises quality and refactoring if there are scope changes based on MVP release; other risks are highlighted in the attachment/google doc
* Kevin recommended adding Focus Group testing to the plan - User Focus Group Testing tasks is missing from the high level plan; thus, looking at a few options that include Saas services and full service agencies like User Insight
* I will create a detailed meeting minutes document and publish to google drive by this Thursday/Friday. 
* We are expected to give feedback on V1 scope (features), risks, and options by next Monday, 12/30. 
* Waiting for the Sahoja team to confirm a time on Monday - I will setup a zoom meeting invite; also, John B plans to be onsite at our office for this meeting; I will also be there next Monday with Chuck Burford for a different client planning meeting
* David, any feedback or comments based on our call today?
* All, please listen to the recording before we all synch up. Pramod, I think we should all have an internal call before next Monday's Sahoja meeting/cc to discuss next steps from our team. Thoughts?
See Zoom recorded link below:


em191209 - Dr Menawat review of Sahoja project

https://drive.google.com/open?id=1-yQEEheEz5WJBow_0HAdL1tDmg1xHGYZ


m191217 - Sahoja on site

m191217-12-17-2019 Paramount Sahoja Onsite Meeting Notes.docx

Security Planning

Anil’s feedback/recommendations on security:

Made recommendations for seven layer security including

  • reverse proxy

  • 2 VPCs

  • gives you 4 layer security

  • still need app level security

  • Azure protection

  • security network protection?

  • GDPR compliance

  • two factor

  • put userid, password, name in different tables not using referential integrity

  • 32 bit id/guid - table 1, name

  • id, password - table 2, id2

  • id2, username - table 3

  • application controls RI, not database

  • this would pass GDPR

  • machine footprint

  • Fintech level security is a differentiator

  • see OAuth

  • Siemba to come up with security architecture plan/recommendations (action item) - Recommendation is to come up with inside out security plan.


Questions Raised

  1. CRM or ecommerce platform ? can we customize one ?
  2. ORM? -  S> GORM is best
  3. Test platforms??  - S> Chai / Junit —   Postman / Curl  ---- WebDriver / JMeter
  4. MVP target date = 2/4
  5. Post MVP milestone roadmap date = 1/7





Candidate Solutions



Step-by-step guide for Example



sample code block

sample code block
 



Recommended Next Steps