Plan van aanpak. Website voor Bouwkundig Adviesbureau Punte. Hugo Nijhuis John Oelen Frank Hazekamp Cindy Roelofs Ben Wilbers Tim Regelink

Transcriptie

1 Plan van aanpak Website voor Bouwkundig Adviesbureau Punte 2009 Hugo Nijhuis John Oelen Frank Hazekamp Cindy Roelofs Ben Wilbers Tim Regelink

2 Contents 1. Product Backlog Documentatie Kwaliteitsbeheer Website testen Doel van het testen Kwaliteitsattributen Uitwerking van de test Project Organisatie Sofware ontwikkelmethode Proces Planning Risicoanalyse Scores per categorie Onderbouwing van keuzes Bedenken van tickets: Digitaal systeem: Meetingen: Kwaliteitsbeheer: Risico s:

3 1. Product Backlog De Product Backlog is een eisenlijst van de opdrachtgever. Dit zijn de wensen/eisen voor het op te leveren product. De Product Backlog is gesorteerd op prioriteit, met nummer 1 als hoogste prioriteit. De verbeterde website moet in elk geval bevatten; 1. Onmiddellijk duidelijk welke diensten er aangeboden worden ( bedrijf ), de homepage wordt ingericht als dienstenpagina. 2. Mooi ontwerp, het ontwerp moet onderscheidend zijn ten opzichte van de concurrentie. 3. Portfolio, hierin worden gerealiseerde projecten getoond. 4. Stuk herkenning van de huisstijl. 5. Alle gegevens moet opdrachtgever zelf kunnen wijzigen. 6. Routeplanner in de contactgegevens. 7. Projectgroep mag zelf initiatieven voorstellen, de opdrachtgever geeft ons de vrijheid naar eigen inzicht detailkeuzes te maken. 3

4 2. Documentatie Hieronder een overzicht welke documentatie er moet worden opgeleverd tijdens het project. Als project en software ontwikkelmethode wordt er SCRUM gebruikt. Hierdoor is de documentatie die wordt opgeleverd minimaal. Allereerst is er een plan van aanpak gemaakt. Dit vormt de basis van het project. In principe is alles wat aan documentatie wordt opgeleverd digitaal. Iedereen van de groep heeft toegang tot het systeem. Het systeem is na registratie toegankelijk via de hieronder staande link: 4

5 3. Kwaliteitsbeheer 3.1 Website testen (Ook wel Proces review Testing genoemd) Een ontwikkelde website dient ten alle tijden getest te worden, dit omdat het een ingewikkeld proces is met een hoop technische aspecten. De ontwikkelde website dient (voor zover mogelijk) per revisie naar behoren te functioneren, daarom dient de kwaliteit van een website op een dusdanig manier beheert te worden. 3.2 Doel van het testen Vanuit de makers van de website gezien, is het doel van het testen, het leveren van bewijs dat het ontwikkel en programmeer- werk correct gedaan is en zodat de factuur bij de opdrachtgever ingediend en betaald kan worden. 3.3 Kwaliteitsattributen In de internationale ISO 9126 standaard voor software kwaliteit worden de volgende kwaliteitsattributen gedefinieerd: Functionaliteit heeft betrekking op het bestaan van een set producten/processen en hun specifieke gebruik. Het zijn de producten/processen die beschreven of stilzwijgende behoeften bevredigen. Betrouwbaarheid heeft betrekking op het vermogen van het product/proces om het prestatieniveau onder bepaalde condities voor een bepaalde periode te handhaven. Onderhoudbaarheid heeft betrekking op de benodigde inspanning om gespecificeerde wijzigingen aan te brengen. Bruikbaarheid heeft betrekking op de inspanning benodigd voor gebruik, en op de individuele beoordeling van een dergelijk gebruik, door een bepaalde of gebleken groep van gebruikers. Portabiliteit heeft betrekking op de mogelijkheid om het product van de een omgeving naar de andere om te zetten. Efficiency heeft betrekking op de relatie tussen het prestatieniveau van het product/proces en de hoeveelheid gebruikte middelen onder bepaalde condities. Beheerbaarheid heeft betrekking op het gemak waarmee het systeem in operationele staat kan worden gebracht en gehouden. Wij zullen ons dan ook, bij het testen van de ontwikkelde website, houden aan de kwaliteitsattributen gedefinieerd volgens deze bovenstaande standaard voor software kwaliteit. 3.4 Uitwerking van de test Per ticket zal worden gekeken naar hoe deze het beste getest kan worden, dit verschilt per ticket. Bij sommige zal dit een test van de html/asp code zijn, terwijl bij een andere wordt nagelezen of het een logisch en duidelijk verhaal betreft. 5

6 4. Project Organisatie In deze paragraaf gaan we duidelijk maken wie de opdrachtgever is en wat de activiteiten zijn van deze organisatie. Tevens zullen we ingaan op de samenstelling van de projectorganisatie en de verdeling van de rollen binnen de projectorganisatie. Hiermee willen we een duidelijker beeld scheppen wie de actoren zijn gedurende het project. Het project Web-Presence zullen wij als groep uitvoeren voor de organisatie Bouwkundig Adviesbureau Punte gevestigd aan de Wensinkweg 6 te Losser. De bewindvoerders zijn ing. H.A. Punte en ing. C.S.E. Punte en hebben bouwkundig adviesbureau Punte opgericht in Dit bedrijf is gespecialiseerd in het adviseren over verbouw en nieuwbouwplannen voor woningen, het maken van een voorlopig en een definitief ontwerp tot het uitwerken van de bouwtekeningen en daarbij het begeleiden van de bouwwerkzaamheden tijdens de daadwerkelijke bouw. Het takenpakket van de organisatie bestaat uit: Het ontwerpen. Bouwkundig en technisch tekenwerk. Toetsing aan het bouwbesluit. Bouwfysische berekeningen. Bestekken. Aanvraag vergunningen (sloopvergunning,bouwvergunningen,milieuvergunningen,gebruiksvergunningen) Bouwbegeleiding. Na de presentatie van de beschikbare projecten is er naar overleg tussen de aandrager en de begeleiders van het project Web-Presence een selectie gemaakt op basis van de kwaliteiten en kennis van de deelnemers van de minor Web-Presence. Deze selectie heeft voor het project voor de organisatie Bouwkundig Adviesbureau Punte de volgende 6 deelnemers opgeleverd. 6

7 De projectorganisatie bestaat uit totaal 6 personen wel te verstaan: Hugo Nijhuis John Oelen Frank Hazekamp Cindy Roelofs Ben Wilbers Tim Regelink Na overleg tussen de groepsgenoten over het te volgen plan is voor het project de volgende rollenverdeling gecreëerd: Product Owner: Hugo Nijhuis Scrum Master: Frank Hazekamp 7

8 5. Sofware ontwikkelmethode De ontwikkelmethode die wij gaan gebruiken in dit project is SCRUM. SCRUM wordt gebruikt bij software projecten. Het voordeel van deze methode is dat er erg weinig documentatie nodig is, en daarom is een betere concentratie op de core mogelijk. Doordat er elke dag een meeting is, worden problemen op tijd gesignaleerd en blijven bepaalde taken niet tot het eind liggen. Belangrijkste voordelen van SCRUM zijn het verhogen van de effectiviteit van het team en het bewaken van de voortgang van het proces. Problemen worden elke dag besproken, zo is er altijd duidelijk zicht op de voortgang van het proces. Tijdsplanning De tijd wordt per tickets ingeschat op basis van ervaring, direct nadat de tickets zijn opgesteld. Dit gebeurt in de regel op maandag aan het begin van de sprint. Werkindeling De op maandag opgestelde tickets worden op basis van ervaring een aantal uren toebedeeld. Ook worden een of meerdere groepsleden aan een ticket toegewezen. De tickets verlopen via een digitaal systeem ( zodat ook vanuit huis de status van het project op ieder moment duidelijk is. Afspraken De afspraken die gelden binnen onze groep zijn formeel vastgelegd. Iedereen is duidelijk dat je op de afgesproken tijd aanwezig bent, wanneer je meer dan een kwartier te laat komt moet je contact opnemen met een ander groepslid. Wenselijk is het een week van te voren te melden bij een ieder van de groep bij afwezigheid. Ook wordt er een daily stand-up gehouden. Omdat het niet voor iedereen even eenvoudig is om op school te komen, is in overleg afgesproken dat elke dinsdag en donderdag om uur via msn een daily meeting wordt gehouden. Op deze manier kunnen eventuele problemen worden overlegd. Het overleg zal ongeveer 15 minuten duren en iedereen zal zeggen wat hij/zij heeft gedaan, wat je vandaag gaat doen en of er ergens problemen zijn ontstaan. Deze 3 vragen zullen door de SCRUM master worden gesteld. Afspraken per week zien er dus als volgt uit; Maandag: 09:30 Lokaal 1.16 Dinsdag: 11:00 MSN Woensdag: 12:00 Lokaal 1.16 Donderdag: 10:00 Lokaal 1.16 Vrijdag: 11:00 MSN Van alle Tutoruren die iedere week plaatsvinden worden notulen gemaakt, die via de mail worden verzonden naar dhr. Jannink, dhr. Zielman en naar alle groepsgenoten. 8

9 6. Proces Tijdens het project houden we sprints van één week aan. Aan het einde van de derde sprint willen we de eerste minimalistisch werkende versie van het product klaar hebben. Dit vinden we voor de eerste en tweede week te optimistisch om helemaal correct te doen. Veel van onze tijd zal gaan zitten in het ontwerp en analyse deel van de website omdat het een grafisch hoogstandje moet worden welke aantrekkelijk is voor een breed publiek. Contactmomenten tussen de Product Owner (Hugo Nijhuis) en de opdrachtgever (Punte Advies) vinden ieder weekend na een sprint plaats. 9

10 7. Planning De detailplanning zal elke maandag worden gemaakt. Elke week vindt er een sprint plaats. Hierin bepaalt de Product Owner (Hugo Nijhuis) welke onderdelen van de Product Backlog in de sprint komen. Hierna word gekeken welke tickets daarvoor aangemaakt moeten worden en naar de prioriteit ervan. De detailplanning gaat dus over een week. Op basis van ervaring van de teamleden worden de taken verdeeld. Zo weten we bijvoorbeeld dat iemand met veel technische ervaring een bepaalde taak sneller maakt dan een ander teamlid met minder ervaring. We werken hiermee volgens de SCRUM richtlijn, want daarbij worden sprints vastgesteld van een vaste periode (die wij op een week hebben gesteld) en wordt een verzameling tickets samengesteld (de Sprint Backlog). 10

11 8. Risicoanalyse Bij een risicopercentage > 50% dient het project niet in deze vorm te worden uitgevoerd. Categorie Risico Waarde * Factor ** Zwaarte ** Risico totaal Tijdsfactor 1 Geschatte looptijd van het project 0-3 maanden Kent het project een definitieve deadline? Ja Is de tijd voldoende om het project te realiseren? Voldoende Complexiteit van het project 4 5 Aantal functionele deelgebieden dat betrokken is Aantal functionele deelgebieden dat gebruik gaat maken van de resultaten Gaat het om een aanpassing of een nieuw project? Grote aanpassingen In hoeverre zullen bestaande verantwoordelijkheden moeten wijzigen? Niet Zijn er andere projecten afhankelijk van dit project? Nee Wat zal de houding zijn van de gebruikers? Geïnteresseerd De projectgroep Zijn er deelprojecten, is de voortgang afhankelijk van de coordinatie hiertussen? Enigszins Welke medewerkers werken aan het project mee? Voorn. externe Wat is het geografische spreiding van de projecten? Aantal projectleden dat op piektijden > 80% betrokken is 14 Verhouding materiedeskundigen tov projectdeskundigen Goed Nemen gebruikers deel aan de projectgroep? In beperkte mate De projectleiding 16 Is de projectleiding materiedeskundig? Redelijk deskundig 17 Hoe deskundig is de projectleiding mbt de projectplanning? Redelijk deskundig Hoeveel ervaring heeft de projectleider met projecten als deze? 19 Hoe deskundig zijn de adviseurs op het te onderzoeken gebied? 20 Hoe deskundig zijn de materiedeskundigen op het te onderzoeken gebied? 21 Hoe betrokken zijn de verantwoordelijke lijnmanagers bij het project? Redelijk veel ervaring Redelijk deskundig Redelijk deskundig Beperkt betrokken Is de kans groot dat de samenstelling van de projectgroep wijzigt tijdens het project? 23 Worden door de projectgroep standaardmethoden gebruikt? Kleine kans Ja, een aantal Categorie Risico Waarde * Factor ** Zwaarte ** Risico totaal 11

12 Duidelijkheid van het project 24 Zijn probleem en doelstelling voldoende bekend bij alle projectleden? De meeste wel 25 Is het onderzoeksgebied nauwkeurig vastgelegd? Niet nauwkeurig Is er voldoende afbakening met andere projecten? Voldoende Is er voldoende tijd gepland voor afstemming en besluitvorming? Voldoende Zijn de randvoorwaarden duidelijk? Ja Werken de randvoorwaarden beperkend genoeg? Redelijk Totaal 152 Risico percentage *** 35,10% * Waarde gekozen door projectleider. ** Hoogte factor en waarde staan vast. *** Risicopercentage is de totaalscore gedeeld door 433 (maximale score) maal 100. Aangezien het risicopercentage een totaalbeeld geeft, kan het zijn dat een bepaalde categorie wel voor een hoog risico zorgt. Hieronder een specificatie per categorie om eventuele verbeterpunten zichtbaar te maken. 8.1 Scores per categorie Categorie (met maximale score versus werkelijke score) Tijdsfactor Maximaal 40 Score 12 Complexiteit van het project Maximaal 80 Score 21 12

13 De projectgroep Maximaal 65 Score 21 De projectleiding Maximaal 129 Score 58 Duidelijkheid van het project Maximaal 119 Score 40 Conclusie: Omdat er gewerkt wordt middels de scrum-methode, is er nog niet een planning vastgelegd die het gehele project overziet. Daarom zullen er risico's ontstaan, omdat nog niet alle zaken duidelijk zijn. Deze worden echter gedurende het project steeds duidelijker. 13

14 9. Onderbouwing van keuzes 9.1 Bedenken van tickets: - De prioritering van de eisen zoals beschreven in de Product Backlog hanteren we ook in de uitwerking ervan. Dankzij deze eisen zijn ons eigenlijk al een paar tickets opgegeven, maar om daadwerkelijk iedere eis volgens de wens van de klant te vervullen, komen er per eis natuurlijk meer tickets bij kijken. Als voorbeeld: de homepagina moet tevens ook de dienstenpagina worden. Hier komen enkele tickets bij kijken als: - Het creëren van de homepagina - Het creëren van de dienstenpagina - De templates bedenken voor elke pagina - De iconen ontwerpen die de diensten aanwijzen - De pagina voorzien van correct Nederlands - Enz. Het bedenken van de tickets doen wij op de maandag om 09.30, een ieder heeft dan inspraak op het proces, en zo kunnen we de rest van de week deze tickets uitwerken. 9.2 Digitaal systeem: - Om vervolgens deze tickets digitaal te krijgen is er een systeem opgezet. Na registratie heeft een ieder van de groep direct toegang tot dit systeem. Op deze manier raken tickets niet zoek. Bovendien zijn de tickets overzichtelijk vanaf elke locatie bereikbaar. (Dit alles in tegenstelling tot het traditionele bord met memo s) wel het geval kan zijn) - Het systeem is opgezet zodat tickets gemaakt, geplaatst, toegewezen, geaccepteerd en gewijzigd kunnen worden. En nog belangrijker, iedereen van de groep kan op een overzichtelijke manier zien wie waar mee bezig is en wat de vorderingen zijn. 9.3 Meetingen: De Daily stand-up vindt dagelijks plaats volgens afspraken uit het schema. (zie Softwareontwikkelmethode) De sporadische daily stand-up die via MSN plaatsvinden, zijn zo georganiseerd omdat niet iedere dag eenieder van ons aanwezig kan zij. Op de afgesproken tijden dient iedereen online te zijn, zodat de Scrum-master een gesprek (met 6 personen samengevoegd) kan beginnen die de voortgang van het proces betreft, gelijk aan de wijze waarop dat gebeurd in het klaslokaal. 9.4 Kwaliteitsbeheer: We hebben in het PVA kwaliteitsbeheer opgenomen, dit omdat het testen van ontwikkelde software dermate van belang is. Van alle tickets die worden uitgevoerd worden, vindt er ook een review plaats. Dit zodat een ieder van de groep van alle zaken op de hoogte is en dat een ieder het eens is met de opgeleverde deelproducten. 14

15 9.5 Risico s: Tijdens het hele proces is er kans op risico. Niet allen zijn te voorspellen maar wel zo goed mogelijk in te schatten, Alle voorziene potentiële risico s staan uitgewerkt in de risicoanalyse. Door met Scrum te werken en dagelijks meetings te laten plaatsvinden moeten grote risico s uit blijven, door kleine problemen zo direct mogelijk op te lossen. Ook zorgt wekelijks contact met de product owner ervoor dat eventuele veranderingen vlot door te voeren moeten zijn. De diversiteit aan specifieke kennis, en het gebrek daaraan kan een struikelblok vormen, het ene groepslid kan een taak voltooien in 5 minuten, terwijl zijn collega daar een middag voor nodig heeft. De opdracht is voor een ieder van ons bedoelt als leerproces, dit kost nou eenmaal meer tijd. 15