p Sahoja
Key Points
References
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 beta | open beta | ||
3 mos | up to 60 partners, 120 vendors, 17K members | ||
6 mos | up 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
- earn tokens on social content, from vendors
- spend tokens on social network, impact projects, purchases
- buy tokens
- 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
- currency value risk
- purchase costs from USD
- redemption costs to USD
- currency exchange fees
- 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
- no currency value risk
- purchase costs from USD
- redemption costs to USD
- currency exchange fees
- 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
- Identify any missing steps
- Propose any adjustments to the existing worksteps
- Identify any risks we did not discuss
- 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
- Documented point valuation process
- Requirement for 100 vendors and 10,000 users prior to V1 launch
- 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.
- 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
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.
- John Bonaccio (JB)
- John Murray (JM)
- David Bishop
- Prentice Stamps
- Kevin Carlson
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
- CRM or ecommerce platform ? can we customize one ?
- ORM? - S> GORM is best
- Test platforms?? - S> Chai / Junit — Postman / Curl ---- WebDriver / JMeter
- MVP target date = 2/4
- Post MVP milestone roadmap date = 1/7
Candidate Solutions
Step-by-step guide for Example
sample code block