mmt - definitiefase
Home

mmt - definitiefase

mmt - definitiefase

In deze fase bepalen we de eisen en wensen die aan het projectresultaat gesteld worden zo nauwkeurig en compleet mogelijk. Het gaat er vooral om de verwachtingen van de betrokken partijen over wat het projectresultaat moet zijn duidelijk op papier te krijgen.

Context

mmt is de afkorting van moe maar tevreden. De website en app moeten het mogelijk maken uitstappen te organiseren voor bijvoorbeeld een school of een hotel. De deelnemers volgen een traject en kunnen feedback geven. Achteraf kan de leraar of begeleider de feedback per deelnemer bekijken en op zijn beurt feedback opstellen. Daarnaast heeft de leraar de mogelijkheid om een ranglijst van de meest enthousiaste deelnemer op stellen.

Functionele eisen

Back-end

  1. Er moet een aparte webapplicatie gemaakt worden om de database te beheren.
  2. Voor elke entiteit moet er een tegel op de index pagina staan waarmee je de entiteit kan beheren (CRUD)
    1. mmt - ERD
    2. mmt - logisch model
    3. Voor de structuur en lay-out baseer je je op:
      1. Fric-frac Opmaak met CSS
      2. Fric-frac Postioneren met CSS
      3. Fric-frac Wireframes
  3. Alleen de DIRECTOR heeft toegang tot deze website.
  4. De DIRECTOR moet over een UI beschikken waarmee hij tours kan uitstippelen.
  5. De back-end wordt gemaakt in .NET MVC Core 3.1. en MySQL, dus geen MSSQL!
  6. De front-end wordt gemaakt zoals we Fric-frac hebben gemaakt in Programmeren 3:
    1. je schrijft dus zelf de HTML ;
    2. en je gebruikt de CSS van dit project.;
    3. dus geen React en ook geen Bootstrap!

Front-end

  1. Eerste fase
    1. De website moet een aangepaste lay-out hebben voor de horizontale- en verticale stand van het toestel.
    2. Er moet een gepast kleurenpalet gekozen worden, rekening houden met logo:
      mmt-logo
      mmt-logo
    3. De website moet de gps gegevens opvragen en weergeven.
    4. stad en land waar de gebruiker zich op dat moment bevindt (GPS);
    5. een keuzemenu waarin alle bezienswaardigheden opgelijst staan
    6. zoekveld om naar een bezienswaardigheid te zoeken
    7. De niet aangemelde gebruiker kan commentaar geven op een bezienswaardigheid (username en email opgeven).
    8. Voor elke bezienswaardigheid een LikePanel
    9. Bezienswaardigheid aanduiden op kaart
  2. Tweede fase (user account toevoegen)
    1. De gebruiker moet zich kunnen aan- en afmelden.
    2. Wanneer de gebruiker zich voor de eerste keer aanmeldt op de mmt-applicatie worden zijn gegevens en zijn rol van de server gedownloaded op zijn device.
    3. De website start met (home pagina) :
      1. de gegevens van de gebruiker als die is aangemeld:
        1. voornaam en familienaam;
        2. functie (rol) binnen de organisatie (deelnemer, begeleider, eigenaar, enz.);
    4. Mogelijke rollen:
      1. direct verantwoordelijke (DIRECTOR)
      2. begeleider (SUPERVISOR): alles wat deelnemer kan + bezienswaardigheid toevoegen
      3. deelnemer (USER): alles wat gast kan + foto's opsturen
      4. gast (GUEST): kan commentaar opsturen, mits het meesturen van e-mail adres
    5. Als de gebruiker is aangemeld worden de voor hem specifieke mogelijkheden getoond (commentaar geven, foto toevoegen, bezienswaardigheid toevoegen, enz.).
    6. De beheerder van de MMT website/app moet die loggegevens kunnen raadplegen op een website.
    7. Wanneer de gebruiker op een bezienswaardigheid klikt moet de website of de app de mogelijkheid bieden dat de actie gelogd wordt en wanneer er connectie met WIFI is moeten de loggegevens naar de server gestuurd worden. De gegevens die moeten worden verstuurd zijn:
      1. naam van de gebruiker;
      2. het email adres van de gebruiker;
      3. rol van de gebruiker;
      4. de titel en code van de bezienswaardigheid;
  3. Derde fase: mogelijkheid toevoegen om tours te maken
    1. een tabel met de naam Tour toevoegen
    2. naam van de tour
    3. bezienswaardigheden toevoegen
    4. in de hoofdpagina de mogelijheid toevoegen om een tour te kiezen
    5. de tourpagina bestaat uit tegels met de beknopte informatie over de gekozen tour
    6. doorklikken naar de detailpagina van de tour
    7. een kaart met de bezienswaardigheden van de tour
  4. Vierde fase (mobiele app)
    1. De mobiele app moet de camera functie van het device kunnen aanspreken.
    2. De gebruiker kan een foto posten van de bezienswaardigheid.
    3. Informatie: React-native - Beginnen
    4. contacteer eventueel max.loubry@ap.be

Niet-functionele eisen

  1. Supportability
    1. Documentatie (Word of OneNote) tijdens ontwikkeling
    2. PDF einddocumentatie

Operationele eisen

Operationele eisen gaan over de eisen aan het gebruik van het projectresultaat.

  1. De slordigheid bij het uitvoeren van de procedures moet met 90% afnemen.
  2. Door een logboek bij te houden is mogelijk om achteraf een analyse te maken van wat er is mis gelopen.

Ontwerpbeperkingen

Ontwerpbeperkingen zijn eisen die te maken hebben met de realisatie van het project zelf.

  1. Een native app is uitgelsloten omdat de app op alle mobiele platformen moet draaien, daarom wordt er gekozen voor React-native.
  2. Voor de oefening voor deze module beperken we ons tot:
    1. gast
    2. deelnemer
    3. geen loggegevens
  3. Aangezien we niet veel tijd hebben, gaan we niet beginnen met het authenticatie gedeelte te implementeren. Dat doen we alleen als er tijd genoeg is.
  4. De opdrachtgever wil zo snel mogelijk een resultaat. Dat wil zeggen dat we volgens de agile methode gaan werken:
    1. Snel schakelen
      Tijdens elke sprint wordt een functionaliteit gerealiseerd. Gedurende het project kan blijken dat een bepaalde functionaliteit aangepast, toegevoegd of weggelaten moet worden. Op basis van voortschrijdend inzicht kan op tijd worden bijgestuurd en wordt voorkomen dat naderhand grote aanpassingen gedaan moeten worden.
    2. Elke twee weken een werkend product
      Met elke sprint wordt een werkend product opgeleverd, dat direct getest en gebruikt kan worden. Als klant kunt u het systeem geleidelijk in productie nemen. U hoeft dus niet te wachten tot de oplevering van het gehele project om te profiteren van uw nieuwe CRM systeem.
    3. Optimale ROI (return in investment)
      De genoemde voordelen van een agile (scrum) aanpak, zorgen ervoor dat de ROI (return in investment) van app implementatie wordt gemaximaliseerd. Door een optimale controle over het project en de mogelijkheid om snel in te spelen op veranderende prioriteiten, omstandigheden en behoeften, zijn we verzekerd van een werkend systeem te produceren binnen de tijdslimiet van deze module.
    4. Nog eens kort samengevat: basis van Agile en ROI:
      1. Agile is concerned with getting the fastest ROI
      2. Continuous iterative development
      3. Progressive incremental delivery
        1. to provide Business Benefit throughout the development
      4. Driven by costs and timescales
        1. Functionality is removed or deferred
      5. Assumes not everything is known
        1. Anticipates Change will happen
      6. Fast feedback supports continuous improvement
      7. Collaborative working between
        1. between Client and Supplier
        2. Development teams Project Realization
    5. We gaan zoveel mogelijk implementeren, maar gezien de beperkte tijd kiezen we ervoor de opdracht op te splitsen in kleinere zelfstandig uit te voeren opdrachten die we kunnen afwerken zonder dat daarom het geheel afgewerkt moet zijn.

JI
2020-07-07 17:46:33