A guest lecture I did at the University of Utrecht for 1st year students

1. App Development
Door:
Rob Vermeulen
Spring Morning Software
http://www.springmorning.nl/

2. Agenda
• Inleiding
• Mijn processtructuur
– PACT analyse
– Use Cases
– Functie Punt Analyse
– Iteratief en evolutionair Ontwikkelen
• Richtlijnen, principes en tips voor Apps
– Algemene User Interfaces, vuistregels
– App Specifieke user interfaces
– Tip en frameworks
• Vragenuurtje

3. Processtructuur Spring Morning
Ontwikkeling
PACT Use
Requirements in iteraties Oplevering
Analyse Cases
(agile)
Indicatief Globaal Detail
Functie Punt Analyse (FPA)

4. PACT Analyse
• Persons, Activities, Contexts, Technologies
• Een raamwerk om betrekkelijk snel de
onderwerpen te benoemen die in de
ontwerpfase van toepassing zijn.
• Globaal beeld van het gebruik van het systeem
• Nuttige input voor Use Cases en requirements
specificaties

5. People
PACT Analyse
Autohandelaars, -importeurs en -merkdealers zijn de doelgroep.
Deze mensen zijn gewend te werken met een computer, dus er is een basiskennis aanwezig. Werken met een smart phone of tablet wordt minder vaak gedaan, dus is een eenvoudige en duidelijke
gebruikersinterface noodzakelijk.
De gebruikers zijn gemotiveerd en hebben een drukke agenda.
De gebruikers hebben verstand van auto’s, autorestwaardes en het daarin gebruikte vakjargon.
Het is mogelijk dat er mensen gebruik maken van het product die een andere taal spreken.
Toegankelijkheid van het systeem moet toestaan dat mensen met kleurenblindheid de app ook kunnen gebruiken.
Activities
Deze taken zullen de gebruikers uitvoeren met onze applicatie:
• Autogegevens van eigen fleet bekijken (foto’s, prijzen, technische specificaties )
• Een auto toevoegen aan de fleet
• Foto’s toevoegen
• Auto’s verwijderen
• Autogegevens wijzigen
• Restwaarde automatisch laten bepalen
• Eenvoudig publiceren op de beschikbare online verkoopkanalen (Marktplaats, Autotrack, Autotrader, Autoweek, Autoscout24, NederlandMobiel.nl etc.)
• Auto’s aan- en afmelden bij het RDW
Contexts
De activiteiten vinden plaats als de gebruiker:
• Een tweedehands auto heeft binnengekregen en de gegevens wil invoeren
• Bestaande informatie wil inzien en/of wijzigen
• Een of meerdere auto’s wil publiceren op online verkoopkanalen
• Een auto heeft verkocht
Een individu of een grote groep mensen kunnen gebruik maken van de applicatie.
Gebruikers hoeven geen hulpmiddelen mee te brengen om de applicatie te bedienen.
Technologies
De deelnemers moeten de applicatie opstarten, dit zal met een simpele druk op een knop gebeuren.
De gebruikersapplicatie zal op een tablet moeten draaien. Zowel Apple (iOS) als Android (versie 4.0+) zal ondersteund moeten worden.
Voor RDW meldingen, restwaardebepalingen en publicaties op verkoopkanalen zal gebruik worden gemaakt van reeds bestaande web services.

6. Use Cases
• Een Use Case is een beschrijving van een gedrag van een
systeem, dat reageert op een verzoek dat stamt van buiten
het systeem. {wikipedia}
• beschrijft "wie" met het betreffende systeem "wat" kan doen.
• Onderdeel van het proces om requirements van een
informatiesysteem te bepalen
• Alle use cases samen definiëren de scope van een nieuw
systeem

7. Mogelijke structuur Use Case
• Use case naam: Een een unieke identificatie voor de use case.
• Versie: Een nummer of tekst dat het stadium van de use case beschrijft
• Doel: Wat wenst de gebruiker met de use case te bereiken
• Samenvatting: De essentie van de use case; een overzicht van de te bereiken interactie.
• Actoren: Een actor is iemand of iets buiten het systeem, dat een interactie aangaat met het systeem.
• Precondities: Definitie van alle voorwaarden waaraan moet worden voldaan voordat deze use case van
toepassing is.
• Triggers: De gebeurtenissen (events), waardoor de use case geïnitieerd wordt
• Basis verloop van de events: een primair scenario, of verloop van de gebeurtenissen
• Alternatieve wegen: Secundaire wegen of alternatieve scenario's
• Post condities: Beschrijving van de eindtoestand van het systeem na het verloop van de use case.
• Business rules: Geschreven of ongeschreven regels of beleid, die bepalen hoe een organisatie dient te
reageren op een bepaalde use case.
• Opmerkingen: Belangrijke aantekeningen, die niet in de vooropgezette format passen.
• Auteur en datum

8. Functie Punt Analyse (FPA)
• een methode om de functionele omvang van een
informatiesysteem te meten door te kijken naar voor
gebruikers relevante functies en (logische)
gegevensverzamelingen.
• De meeteenheid is de “functiepunt” (fp)
• Gebruikt voor o.a. het begroten van een systeemontwikkeling
• Een “break-down” in kleine functiepakketjes

9. Functie Punt Analyse (FPA) (2)
• schatten op basis van ruwe gebruikerseisen en -
wensen (requirements)
• schatten op basis van analogie
• schatten op basis van een eventueel aanwezig
globaal gegevensmodel en/ of procesmodel, al dan
niet compleet.

10. FPA functie types
• Interne Logische GegevensVerzameling (ILGV)
• Koppelings-GegevensVerzameling (KGV)
• InvoerFunctie (IF)
• UitvoerFunctie (UF)
• OpvraagFunctie (OF)

11. FPA Voorbeeldanalyse
Gebruikersfunctie Functietype Complexiteit Functiepunten
(standaard- (bruto)
waarden)
• de gebruiker wil gegevens van Klanten kunnen
toevoegen, wijzigen en verwijderen, wil Klant ILGV Eenvoudig 7
klantgegevens kunnen raadplegen en wil vier Product ILGV Eenvoudig 7
verschillende overzichten met betrekking tot Leverancier KGV Eenvoudig 5
Klanten; deze overzichten bevatten berekende Toevoegen Klant IF Gemiddeld 4
gegevens Wijzigen Klant IF Gemiddeld 4
Verwijderen Klant IF Gemiddeld 4
• de gebruiker wil gegevens van Producten Opvragen Klant OF Gemiddeld 4
kunnen toevoegen, wijzigen en verwijderen, wil Overzicht 1 met betrekking tot Klant UF Gemiddeld 5
productgegevens kunnen raadplegen en wil een Overzicht 2 met betrekking tot Klant UF Gemiddeld 5
overzicht met betrekking tot Producten; dit Overzicht 3 met betrekking tot Klant UF Gemiddeld 5
overzicht bevat berekende gegevens
Overzicht 4 met betrekking tot Klant UF Gemiddeld 5
• de gebruiker wil gegevens van een Leverancier
kunnen raadplegen via het uniek identificerende Toevoegen Product IF Gemiddeld 4
Wijzigen Product IF Gemiddeld 4
leveranciersnummer, en wil ook een overzicht Verwijderen Product IF Gemiddeld 4
met betrekking tot Leveranciers met Opvragen Product OF Gemiddeld 4
totaliserende resultaten Overzicht met betrekking tot UF Gemiddeld 5
Product
Opvragen Leverancier OF Gemiddeld 4
Overzicht met betrekking tot UF Gemiddeld 5
Leverancier
Globale functionele omvang 85 fp

12. FPA valkuilen
Houd rekening met “groei” in het project. We onderscheiden 2 soorten
groei:
• "autonome groei“
– ontstaat doordat functionaliteiten bij detailleren van de specificaties
zichtbaar worden en daarvóór dus ten onrechte niet als functiepunten
waren geteld.
• "scope creep“
– treedt op doordat de klant in de loop van het ontwikkeltraject nieuwe
wensen formuleert. Scope creep leidt dus tot nieuwe functionaliteit
die ook bij detailleren niet zichtbaar zou zijn geworden. Ook wel
“voortschrijdend inzicht” genoemd.
Meer info op http://www.nesma.nl/ (Nederlandse Software Metrieken Associatie)

13. Iteratief & Evolutionair Ontwikkelen
• Ontwerp, ontwikkeling en oplevering in delen (iteraties)
• Eindresultaat niet in detail bekend. Nieuwe inzichten evolueren erin mee.
Voordelen
• Betrokkenheid van opdrachtgever en gebruiker(s)
• Sneller “tastbaar resultaat”
• Beter risicobeheersing door in kleinere stukken te ontwikkelen
• Gemakkelijker om complexe systemen te “behappen”
• Aan het eind van elke iteratie is een bruikbaar product opgeleverd, ook al
wordt verdere ontwikkeling gestopt.

14. Iteratief & Evolutionair Ontwikkelen
Nadelen
• Kans op vervaging en wegdrijven van oorspronkelijk doel (“scope
creep”)
• Omgeving is er niet klaar voor. Project managers die niet kunnen
omgaan met de dynamiek en een vager einddoel.
• Vraagt ervaren sturing
• Kan grote impact hebben op de resources binnen organisaties

15. User Interfaces

16. User Interfaces – Vuistregels
• Zgn. Westerse Aspecten
– Van Links Naar Rechts
– Van Boven Naar Beneden
– Gebruik signaalkleuren (In orde, niet goed)

17. User Interfaces - Doel
• Bedenk wat je wilt bereiken
– Wil je informeren?
• Zorg voor neutrale kleuren die niet afleiden van de inhoud
• Kies een leesbaar lettertype
– Entertainen?
• Zet een sfeer die past bij de inhoud.
• Kies passende audio en afbeeldingen
• Val op.
– Functioneren?
• Zet de belangrijkste en/of meestgebruikte functies centraal

18. User Interfaces - Doelgroep
• Wie of wat is je doelgroep?
– Zakelijk of privé
• Toonsetting, tekstneutraliteit
– Leeftijdscategorie
• Jargon, complexiteit, hoeveelheid tekst, functionaliteit(!)
– Opleidingsniveau
• Zie leeftijdscategorie
– Geslacht
• Kleurkeuze, volgorde van acties
– Mensen met een visuele of gehoorbeperking
• Ondersteunende audiosignalen, of juist niet
• Grotere knoppen, beter onderscheidbare kleuren, hoger contrast

19. User Interfaces –
Hoe bepaal ik de inhoud
• Elke Use Case zijn eigen scherm / schermen
• Elk onderdeel van een workflow zijn eigen
scherm

20. User Interfaces - Voorbeeld
VS

21. User Interfaces voor Apps
• Scherm is doorgaans compacter dan een computerscherm
• Informatie wordt paginagewijs of groepsgewijs getoond
• Doorgaans gegroepeerd op:
– Functionaliteit:
• Bijvoorbeeld “instellingen scherm”
– Relevantie:
• Alles data en functionaliteit die over hetzelfde onderwerp gaat
– Fase in de workflow:
• Bijvoorbeeld een “wizard” scherm

22. User Interfaces voor Apps
• Waar let je op?
– Gebruiker niet meer tekst laten invoeren dan noodzakelijk. Maak
daarom gebruik van:
• Opzoek mechanismen
• Keuzelijsten
• Auto-aanvullen
– Zet de meest gebruikte functionaliteit centraal
– Gebruik knoppen voor acties
– Toon voor elke stap in een workflow een nieuw scherm.
– Zorg dat je kunt navigeren tussen de schermen door middel van
navigatieknoppen én swipe gebaren.
– Zorg dat het ook duidelijk is wanneer je niet kunt navigeren.

23. User Interfaces voor Apps
• Onderscheid tussen smart phones en tablets
Smart phone Tablet
Rechtopstaand Landscape
Verticaal scrollen Horizontaal swipen
Eén tekstkolom Meerdere kolommen
(tekst en navigatie)
Navigatie met swipen Navigatie met
knoppen én swipen
Veel inzoomen Weinig inzoomen
Verborgen menu’s Zichtbare menu’s

24. Een App bouwen?
Waar moet je aan denken?
• Voor welk platform wil ik een App? (iOS, Android, Blackberry, Windows Phone/RT)
– Zoek een ontwikkelomgeving waarmee je voor de gewenste platformen kunt ontwikkelen.
– Steek moeite in het vinden van een tool of framework waarmee je met 1x ontwikkelen,
meerdere platformen kunt bedienen
– Ondersteun niet meer platformen dan noodzakelijk
– Ontwikkel op één platform, porteer het naar de andere(n)
• Voor tablet, smart phone of beide?
– Wie gaat het gebruiken? Is de doelgroep een buitendienstmedewerker, een accountant, een
bouwvakker of een student?
– Hoe wil je het tonen?
– Heb je een koppeling nodig met de bel-functie?
– Overweeg om aparte apps te maken voor tablet en smart phone.

25. Een App bouwen?
Waar moet je aan denken?
• Is een App afdoende, of is er ook een backend noodzakelijk?
– Haalt de app informatie op van het internet?
– Heb je zelf ergens een database on-line waar je informatie uit haalt, of juist in wilt plaatsen?
– Maak je gebruik van web services om meer informatie te verkrijgen?
– Zijn er kosten verbonden aan een externe service?
• Waarmee ga ik het ontwikkelen?
– Kies een technologie die het beste kent (HTML & Javascript, of juist C++)
– Kies een technologie de het beste past (web technologie is eenvoudiger over meerdere platformen te
verspreiden)
– Zoek een “RAD” omgeving. Ontwikkelen in een high-level taal als Python, Ruby of Lua levert vele malen
sneller resultaat dan “native” omgevingen.
– 95% van de apps zijn met web-technologieën prima te realiseren.
• Bied je het aan via een app store? Of is het slechts voor een selecte groep?
– Met Android is het vrij eenvoudig om buiten de app store om apps te kunnen installeren.
– iOS is wat lastiger en vraagt om een Enterprise licentie (€400,- per jaar) als je binnen een selecte groep wilt
blijven.

26. Een App bouwen?
Mogelijke cross-platform frameworks.
• Marmalade SDK.
– C++, Visual Studio
– Ondersteuning voor alle platformen.
– Voor games en applicaties die veel performance vragen.
– Goede community
– Nadelen: Low level ontwikkelen in C++, time to market is traag, prijzig
licentiemodel
• PhoneGap (heet nu Cordova)
– Web technologieën (HTML5, Javascript, CSS)
– Ondersteuning voor alle platformen
– Goede community
– Gratis
– Nadelen: teveel platform specifieke aanpassingen in CSS. Je hebt veel kennis nodig
van CSS om de gebruiker een goede indruk te geven.
• Corona Labs
– High-level script taal Lua
– Ondersteuning voor Android en iOS
– Geschikt voor games, e-books, business apps en web apps
– Veel kant-en-klare voorbeelden en widgets
– Nadelen: Overwegend onbekende taal, dus een leercurve. Eigen
ontwikkelomgeving die niet zo goed werkt op Windows. Op een Apple werkt alles
wel vlekkeloos. Niet gratis

27. Vragen?