Inzicht op software ontwikkelen
Ik wil graag vragen om meer inzicht bij het beginnen van het bouwen van software.
Bijvoorbeeld iets kleins net als tic tac toe spel. Hoe zou je dit benaderen?
- Open vs
- Maak nieuw project
- Maak classes? drawUI bijvoorbeeld, gameflow
- Bedenken wat voor method's je gaat aanmaken.
Als je tic tac toe in stukjes zou hakken wat voor problemen zou je dan zien om op te lossen? En hoe ga je te werk.
Daarnaast zijn er ook enkele noodzakelijke randvoorwaarden zoals:
- een set minimale theoretische kennis
- enig abstract denkvermogen
- kennis over keuzes in gereedschappen, materiaal en (bouw)technieken
Het meeste -of in ieder geval voldoende- (denk)werk is vantevoren al gedaan, daarna volgt pas het uitrollen / daadwerkelijk bouwen. Je begint ook niet zomaar ergens met het bouwen van een huis.
Toegepast op het "tic tac toe" voorbeeld: stel eerst een functionele spec op. Los van techniek beschrijf je wat je gaat bouwen en wat het zou moeten doen. Je beschrijft bijvoorbeeld de verschillende schermen, interactievormen, en de mogelijke zetten die je in het spel kan doen. Ook beschrijf je condities waaronder het spel voorbij is. Eigenlijk dus de set van spelregels en alles wat tijdens een speelronde kan gebeuren.
Maar als je dit concreet wilt maken dan is dit voorbeeld te abstract, je vertelt namelijk niet:
- in wat voor programmeertaal/welke techniek dit gemaakt zou moeten worden
- in wat voor soort applicatie dit zou moeten komen (web? standalone? single player? multiplayer? vs AI?)
-- Voorbereiding --
Functioneel ontwerp
Wat wil je maken en waarom (in dit geval niet zo heel relevant)
Welke requirements zijn er (in dit geval, wat zijn de spelregels)
Wat gebeurt er als er een ongeldige invoer is (bijv: gebruiker klikt op een veld dat al gevuld is)
Hier denk ik vaak ook al na over mijn eerste testcases, omdat nadenken over testcases je een beter inzicht kan geven in waar je technisch op moet letten. Bijvoordbeeld:
Case : Een gebruiker klikt op een veld dat al in gebruik is
Expected : Gebruiker krijgt een melding dat hij/zij een ander veld moet kiezen
Het is belangrijk dat je hierbij objectief blijft. Dus probeer weg te blijven van de "Dit ga ik toch niet fout doen" en de "dit is toch logisch" gedachte gang
-- Hiertussen indien van toepassing laat ik vaak reviewen door de opdrachtgever. Dit is omdat je dan duidelijk op papier hebt/zou meoten hebben wat een opdrachtgever verwacht.
In deze fase kan een opdrachtgever nog aangeven dat hij dingen anders wil of bedoeld
Technisch ontwerp
Ben ik geen held in, maar bij mij is dit vaak de structuur van het systeem dat ik ga opzetten. Classes, database, welke libraries ga ik gebruiken, dingen van die strekking.
-- Ontwikkelen --
Code kloppen
-- Testen --
Test de cases die je in je Funtioneel Ontwerp hebt gedefineerd, alsmede dingen waar je tijdens het ontwikkelen aan denkt (alles van tevoren bedenken is een uitdaging).
(als je een opdrachtgever hebt)
-- Acceptatie --
Je maakt je functionaliteit beschikbaar op een test omgeving waar de opdrachtgever ook bij kan, zodat hij/zij kan testen en eventueel dingen terug kan melden.
Hou hierbij in het achterhoofd dat er een groot verschil is tussen een bug, en toch niet helemaal wat hij/zij had verwacht.
In de perfecte wereld zou je dan kunnen aangeven dat het werkt zoals in de FO gespecced staat, waar hij/zij akkoord ,en dat er na de release een RFC gedaan kan worden.
Speccen is erg belangrijk in dit geval omdat er zo min mogelijk ruimte voor interpretatie in moet zitten.
-- Oplevering --
Livegang van het project
Ben ongetwijfeld dingen vergeten of doe dingen verkeerd, maar dat hoor ik vanzelf :P
https://imgur.com/7pXyqUP
Gewijzigd op 27/10/2018 23:13:54 door Izildo Pimentel