VOS - definitiefase
Home

VOS - definitiefase

VOS - 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

VOS is de afkorting voor Veilig op school. Met deze app moet een school in staat zijn om een efficiënt veiligheidsbeleid in de praktijk te brengen. De app zorgt ervoor dat de procedures, die gevolgd moet worden bij brand, vegiftiging, ongeval, bommelding, blikseminslag, enz, nauwkeurig uitgevoerd worden en dat er een logboek wordt bijgehouden van de uitgevoerde stappen bij elk van deze procedures. Wil je een idee hebben van waar we naar toe willen ga dan naar de EHBO-app voor hulp in een noodsituatie en installeer die op je telefoon.

Functionele eisen

De VOS applicatie valt uiteen in twee delen:

  1. Gebruikersapp op iOS en Android
    1. De gebruiker moet zich kunnen aan- en afmelden met de gegevens van zijn Google account.
    2. Wanneer de gebruiker zich voor de eerste keer aanmeldt op de VOS-applicatie worden zijn gegevens en zijn rol van de server gedownloaded op zijn device. Mogelijke rollen:
      1. directe verantwoordelijk (DV)
      2. Leraar/Docent/Opvoeder (LDO)
      3. gast (GAST)
    3. De app start met (home pagina) :
      1. de gegevens van de gebruiker als die is aangemeld:
        1. voornaam en familienaam;
        2. functie (rol) binnen de school (leerkracht, docent, directeur, CLB, veiligheidsadviseur, enz.);
        3. nummer van de telefoon waarop de app draait;
        4. naam en adres van de school waar het personeelslid zich op dat moment bevindt (GPS);
        5. telefoonnummer van die school
      2. een keuzemenu waarin alle procedures opgelijst staan:
        1. Brand
        2. Ongeval (leerling en leraar apart)
          1. Extra muros
          2. EAO (ernstig arbeidsongeval)
          3. AO (arbeidsongeval)
          4. Van en naar de school
        3. Gaslek
        4. Schokkende gebeurtenis
        5. Amok/Geweld
        6. Radicalisering
        7. Terreurdreiging
          1. Bomalarm
          2. Verdacht voorwerp
          3. Terroristische aanslag
        8. Radicalisering
        9. Psycho-sociaal risico
          1. Ongewenst gedrag (seksueel, stalking)
          2. Geweld
          3. Pesten
          4. Burn-out
      3. Als de gebruiker is aangemeld worden de voor hem specifieke te volgen procedure getoond (brandweer bellen, noodplan afkondigen, enz.).
      4. Als de gebruiker niet is aangemeld wordt de basisinformatie getoond maar is er geen mogelijkheid om noodnummers te bellen of te sms'en.
      5. Een beschrijving van procedures vind je op Crisisscenario's van het GO. Ga naar actiekaarten om meer info over procedures te vinden.
    4. Als de gebruiker een bepaalde procedure selecteert begeleidt de app hem/haar stap voor stap doorheen de procedure. Tijdens het doorlopen van de procedure moet de gebruiker steeds in staat zijn een stap terug te zetten.
    5. De app moet een aangepaste lay-out hebben voor de horizontale- en verticale stand van het toestel.
    6. De mobiele app moet de volgende functies van het device kunnen aanspreken:
      1. telefoon
      2. sms
      3. gps
      4. camera
    7. Wanneer de gebruiker met de app belt of sms't moet die actie gelogd worden en wanneer connectie met WIFI naar de server gestuurd. 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 procedure;
      5. de titel van de stap in de procedure;
      6. het telefoonnummer waarnaar gebeld of gesms't wordt;
      7. het telefoonnummer waarvan gebeld of gesms't wordt;
  2. De beheerder van de VOS app:
    1. gebruikersbeheer
    2. procedurebeheeer
    3. moet die loggegevens kunnen raadplegen op een website;

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. Voor de oefening voor deze module beperken we ons tot drie rollen:
    1. DV
    2. LDO
    3. Gast
  2. 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-10-03 07:59:28