Vi har skissat på lite olika chapters, väldigt löst, och försökt resonera (kort) om vad för dependencies som uppstår mellan dem, vi utgick först från våran arkitektur
| Lager |
|---|
| Front-end (Web UI) |
| Web Server |
| Business Layer (Video, Cache, DB-interface, Authentication) |
| Databas och long-term storage |
och funderat över utomstående chapters, samt försökt fånga de som vi inte tror kommer ta den specifika personen (personernas) hela tid.
-
Front-end, ansvarar för att ta fram ett användarvänligt gränssnitt och i förlängningen göra det estetiskt tilltalande. De kommer dessutom få jobba för att fånga video i webbläsaren och överföra denna information från webbläsaren till underliggande lager. Förslagsvis kan de jobba med WebRTC (kanske NextRTC) ramverket och tillsammans med underliggande lager hitta en kommunikations kanal för att översätta den fångade live-datan till överförbara video filer gentemot servern.
Vidare kommer de dessutom jobba mot en analys grupp (beskrivs senare) som kommer ha som en bi-syssla att analysera användare->system data, däribland kvalitéen på video/audio/uppkoppling.
-
Webb-server. Detta lager kommer jobba tillsammans med front-end gruppen för att exponera, från underliggande lager, den funktionalitet som påverkar slutanvändar upplevelsen. Till exempel, omsätta en lyckad login till data som webb-server gruppen kan ta emot och vidare förmedla till front-end.
Dessutom kommer de behöva agera som en intermediär (i stil med en medlare/kurir) för att överlåta användar-input till det underliggande affärslagret.
-
Affärslager, här finns möjlighet att skapa flera chapters, och berör främst överlämnandet av video till långtidsförvaring och att från förvaringen kunna ge tillbaka video-data till överliggande lager. Eftersom vi har många samtidiga användare (studenter), så behövs det troligtvis ett smart sätt att kunna snabbt ge studenter lärarens fråga. De ser inte alla denna video exakt samtidigt och således behöver vi nog bibehålla denna information i snabbt minne (RAM) så vi emulerar en sorts cache.
Här sker även kommunikation mot utomstående API:er som exempelvis CAS och i förlängningen kanske även Cambro och Moodle för att lagra betyg.
Summeringsvis behöver det/de chapter(s) som utgör dessa ansvarsområden:
- Sköta video in- och ut mellan webbservern->förvaring/cache och långtidsförvaring/cache->webbserver.
- Autentisering
-
Databas, designa ett så kallat schema och synkronisera de behov som uppstår i ovanstående lager, vi kan föreställa mig att avklarade tentor, kommande tentor, etc. kommer vara sådant vi behöver lagra utöver refenser till video arkivet.
Chapters utanför arkitekturen:
- Continous integration, exempelvis mha Travis (om hela systemet är enspråkigt och i ett repo) annars Jenkins (alt. flera repo:n). Travis är enkelt men stöder inte multi-språk system. Jenkins är svårare. Mycket svårare.
- Produktägare/Scrum Master (Kan delta i möten mellan squads, Scrum of Scrums)
- Arkitekt, har ett högnivå ansvar för att bibehålla en enhetlig design mellan squads. Blir nog en del möten, kanske Scrum of Scrums med andra arkitekter. Code-reviews? (formella och informella? för att snabbt kunna reager på avvikelser från en enhetlig design men även tillåta intern autonomi i det interna systemen. Alltså, mestadels försöka bibehålla en enkel API utåt) och fundera över (Rest) API:er mellan komponenter. Gränsytor i princip.
- Säkerhet, behöver ha koll på regler kring att lagra persondata och synkronisera med databas lagret, eventuellt ta fram terms and conditions som avsäger ansvar från missbrukandet av videos, och utifrån dess kunskap om dessa regler kunna konsulteras av andra i squad:en, dokumentera dessa regler enhetligt mellan squads för överlämning till nästa år och ha vetskap om var information den saknar går att hitta.
- Analys, samlar användardata, kraschrapporter, ge feed-back på video- och ljudkvalité etc. och jobba för ett robust och välmående system. Behöver ha tät kommunikation med front-end lagret och business lagret.
Inom våran "squad" så har vi arbetat på sådant vis att varje person har fått yttra sig om saker de skulle kunna tänka sig jobba på och vad de absolut inte kan tänka sig jobba på och därefter försökt definiera vilka som axlar vad. Detta är för att många individer kan tänka sig jobba med flera ansvarsområden men de kan omöjligen ha tid till att jobba med samtliga.
Till exempel har en sagt att den kan
| Kan tänka sig jobba med | Vill absolut inte jobba med |
|---|---|
| Webbserver och kringliggande teknologier | Databas |
| Front-end | Affärsregler och säkerhets aspekter |
Vi förmodrar att de som axlar ett "chapter" beslutar tillsammans vilka teknologier de vill jobba med och kommunicerar med varandra om nya lärdommar de får under deras arbete.
Inom våran grupp så har vi bra täckning på Front-end, Video & API mellan Webbserver & Databas-lagret. Det finns visst, men inte starkt, intresse för att jobba med Affärsregler utan våran "vision" är att jobba mer implementationsnära. En vill jobba mycket med CAS, Cambro och Moodle. Det finns egentligen inget visat intresse för databaser.
En har tidigare erfarenhet att skapa kontinuerligt körande test när det pushas till master grenen på Git sålänge projekter är i ett programmeringsspråk.