Proftaak Software Engineering P3

Proftaak Software Engineering P3

Versie 1.4 Juli 2011 Tom Broumels Jelle Oosterkamp Stefan Roijers Sjaak Verwaaijen

1

versie

datum voltooid

auteur

1.0

Aug 2010 Sjaak Verwaaijen

1.2

Nov 2010 Sjaak Verwaaijen

Wijziging

Beoordeling schema uitvoering naar docenthandleiding Opdrachtgever info toegvoegd.

1.3

Dec 2010

Sjaak Verwaaijen

RFID info toegevoegd

1.4

Juli 2011

Sjaak Verwaaijen

Prodrive info toegevoegd. Beoordeling beter opgeschreven

2

Inhoudsopgave

Inhoudsopgave ........................................................................................................................................ 3 Inleiding .................................................................................................................................................. 5 Doelstelling ........................................................................................................................................ 5 Vereiste voorkennis ........................................................................................................................... 5 Het bedrijf ............................................................................................................................................... 6 Het werkveld ....................................................................................................................................... 6 Bedrijfscultuur ..................................................................................................................................... 6 Organisatiestructuur............................................................................................................................ 6 Directie ............................................................................................................................................ 8 Afdeling HRM .................................................................................................................................. 8 Afdeling Administratie ..................................................................................................................... 9 Afdeling Software ............................................................................................................................ 9 Afdeling Information Management .................................................................................................. 9 Afdeling Infrastructuur................................................................................................................... 10 Communicatielijnen........................................................................................................................... 10 Opdrachtbeschrijving ............................................................................................................................ 11 Toelichting SME-Concept ................................................................................................................... 11 SME-concreet .................................................................................................................................... 11 Systemen........................................................................................................................................... 12 Infrastructuur .................................................................................................................................... 13 Databases .......................................................................................................................................... 13 Software ............................................................................................................................................ 14 Testen ............................................................................................................................................... 14 Overige eisen..................................................................................................................................... 15 Hulpmiddelen. ................................................................................................................................... 15 Bedrijf versus School ............................................................................................................................. 16 Rollen ................................................................................................................................................ 16 Consultant ..................................................................................................................................... 16 Opdrachtgever............................................................................................................................... 16 3

Prodrive......................................................................................................................................... 16 Studentrollen binnen het project ....................................................................................................... 17 Fasering en producten ........................................................................................................................... 19 Inwerkfase......................................................................................................................................... 19 Ontwerpfase...................................................................................................................................... 19 Bouwfase .......................................................................................................................................... 19 Afrondingfase .................................................................................................................................... 20 Beoordeling ....................................................................................................................................... 20 URS................................................................................................................................................ 20 Eindproduct ................................................................................................................................... 20 De uitvoering ................................................................................................................................. 21 Oplevering............................................................................................................................................. 22 Interne oplevering ............................................................................................................................. 22 Oplevering aan opdrachtgever ........................................................................................................... 22 Oplevering voor school ...................................................................................................................... 22 Kwaliteitszorg ........................................................................................................................................ 22 Tools ................................................................................................................................................. 23 Gebruik van Oracle en SVN van buiten het Fontys netwerk ............................................................ 23 Testen ............................................................................................................................................... 23 Professionalisering ............................................................................................................................ 23 Vastleggen afspraken......................................................................................................................... 23 Bijlage 1: User Requirements Specification (Document van Eisen) ......................................................... 25 Bijlage 2: Plattegrond Camping ............................................................................................................. 26 Bijlage3: Koppeling URS-Klasse-Test ...................................................................................................... 27 Bijlage 4: Acceptatietestdocument layout .............................................................................................. 28

4

Inleiding In het eerste semester van de propedeuse heb je al kennis gemaakt met de proftaken van P1 en P2. In deze proftaken leerde je in een groep echte taken in een realistische opdracht uit te voeren. 1 Je hebt nu gekozen voor het profiel Software Engineering en we gaan weer een stap verder in het benaderen van de beroepspraktijk. In deze proftaak zal je gaan werken met een opdrachtgever en binnen een organisatiestructuur van een fictief bedrijf. We hebben daarvoor zogenaamd een bedrijf opgericht genaamd Ict4Events, waar je tijdelijk bent aangenomen op projectbasis. Tijdens dit project kan je laten zien wat je in je mars hebt. De proftaak zal zich natuurlijk focussen op de belangrijke pijlers van het vakgebied software engineering zoals Databases, Programmeren en Netwerken.

Doelstelling Doel van deze proftaak is om op het gebied van software ontwikkeling, infrastructuur en databases kennis en vaardigheden integraal te verwerven in een boeiende en praktische context. De proftaak wordt parallel aan een aantal ondersteunende vakken aangeboden

Vereiste voorkennis Om deze proftaak succesvol te kunnen starten moet je de volgende module voldoende beheersen: SE12 DS122

Om de proftaak volledig te kunnen afronden moeten alle ondersteunende modules eveneens gevolgd worden: SE21 IN21 DBS21 SLB/BV In dit document wordt eerst het bedrijf geschetst waarin je komt te werken. Hierna wordt de opdracht toegelicht en tenslotte komen schoolse zaken aan de orde zoals; studentrollen, de rollen die de docenten hebben en de beoordeling van de proftaak.

1 2

Voor studenten van het verkorte traject is dit wel nieuw Voor studenten van het verkorte traject komen deze onderdelen in SE21v en DBS21v aan de orde.

5

Het bedrijf In dit hoofdstuk wordt het werkveld, de cultuur en de organisatiestructuur van het bedrijf Ict4Events toegelicht.

Het werkveld Ons bedrijf Ict4Events heeft zich gespecialiseerd in de ICT-ondersteuning bij grote evenementen in Europa. Het gaat hierbij meestal om muziek, media of sportevenementen. De evenementenbranche is een groeimarkt en wij willen een grote speler in deze bedrijfstak zijn. Dit willen we bereiken door hoogwaardige software te bouwen wat op verschillende soorten evenementen snel en flexibel ingezet kan worden. Hierbij maken we zoveel mogelijk gebruik van herbruikbare softwarecomponenten. Deze componenten maken we in principe zelf. We gebruiken onze eigen software in combinatie met state-of-the-art producten op het gebied van infrastructuur. De ICT bij evenementen is divers en afhankelijk van het type event, maar Ict4Events is staat om systemen op maat te leveren voor de infrastructuur, reclameuitingen, boekingen & registratie, toegangscontrole, muziek & belichtingondersteuning en filesharing met download.

Bedrijfscultuur Ict4Events is een organisatie met jonge creatieve professionals. Wij zijn gewend met verschillende disciplines tegelijk te werken en vragen onze medewerkers over de grenzen van het eigen vakgebied heen te kijken. Dit vraagt creativiteit en geeft ontplooiingskansen. Dat betekent dat je zelfstandig kunt werken maar net zo gemakkelijk in samenwerking met collega’s en opdrachtgevers tot resultaten kunt komen die passen bij het kwaliteitsbeeld van ons bedrijf. Praktijkgerichte oplossingen liggen niet standaard op de plank en vereisen een creatieve en vaak ook innovatieve aanpak. Wij zijn niet alleen geïnteresseerd in wat iemand kan, maar ook in wat hij wil! Door hier actief mee bezig te zijn en initiatieven te ontwikkelen, kan iemand zelf richting geven aan zijn loopbaan bij Ict4Events. Bij Ict4Events werken betekent werken in een informele organisatie waar medewerkers, ongeacht hun functie, ontspannen met elkaar omgaan. De cultuur bij Ict4Events is zeer open. Heb je een eigen mening en wil je graag ideeën inbrengen, dan waarderen we dat. Als je kritisch kunt meedenken met de opdrachtgever, met integriteit en zorgvuldigheid opereert, je enthousiasme niet snel verliest en niet in de laatste plaats kostenbewust kunt werken, dan zul je je bij Ict4Events snel thuis voelen.

Organisatiestructuur Ons bedrijf past een projectorganisatie toe om gebruik te kunnen maken van diverse specialismen en disciplines van de afdelingen. De projecten moeten leiden tot betere bedrijfsresultaten van onze organisatie. Het project dat jullie gaan uitvoeren wordt ondersteund door experts van verschillende afdelingen. Na beëindiging van het project kan het dienstverband omgezet worden naar een tijdelijk dienstverband op een van de afdelingen. Vanuit die afdelingen kun je dan weer geplaatst worden bij één of meerdere projecten.

6

Het personeel van Ict4Events is grofweg te verdelen in 3 groepen de artiesten, de softwareengineers en de netwerkspecialisten. De artiesten houden zich bezig met grafische en geluidseffecten die bij verschillende events gebruikt worden. De software-engineers houden zich, afhankelijk van hun ervaring, bezig met softwareontwerp en het implementeren hiervan. Maar zij kunnen ook gespecialiseerd zijn in databaseontwikkeling. De netwerkspecialisten ontwerpen en rollen netwerken uit voor de verschillende evenementen. Het ontwikkelteam staat niet in direct contact met de eindgebruiker maar de contacten lopen via de productmanagers en de opdrachtgever. De kwaliteit van het product wordt mede bewaakt door deze productmanagers. Zij zijn in staat om te beoordelen of een tussenproduct tot een goed eindresultaat leidt. ICT4Events heeft een platte projectorganisatiestructuur: naast de directie kennen we nog één hiërarchische laag, namelijk de hoofden van de ontwikkelafdelingen en de stafafdelingen. ICT4Events kent de volgende ontwikkelafdelingen: Software engineering Information Management Infrastructuur Media Verder zijn er nog de stafafdelingen personeel en organisatie (HRM), public relations (PR) en de afdeling financiën (FIN). Hieronder is het organogram van de projectorganisatie van jullie project weergegeven. Je werkt binnen 3 afdelingen en legt verantwoording af aan de productmanager. Het volledige organogram (met alle (staf)afdelingen) is op aanvraag beschikbaar.

7

Algemene leiding

Afdelingshoofd

J. oosterkamp

S. Verwaaijen

T. Broumels

S. Roijers

Afdeling software engineering

Afdeling Information management

Afdeling Infrastructuur

Productmanager

Productmanager

Productmanager

Productmanager

Directie De directie wordt gevormd door een algemeen directeur, het hoofd HRM en de hoofden van de ontwikkelafdelingen. De dagelijkse gang van zaken binnen het bedrijf is in handen van Dhr.J. Oosterkamp Afdeling HRM De afdeling HRM is o.a. verantwoordelijk voor het aanname beleid, het voeren van de functioneringsgesprekken en het bijhouden van de persoonlijke dossiers. ICT4Events staat bekend om haar cultuur die medewerkers ontplooiingskansen biedt. Tegelijkertijd wordt er gewerkt in teams. Dat vraagt een investering in een heel scala aan competenties. De afdeling HRM biedt medewerkers daarbij coaching, maar houdt tegelijkertijd het belang van de teams in de gaten.

8

Binnen een project heeft de afdeling HRM de volgende taken: 





Door de projectorganisatie structuur van ICT4Events solliciteren de medewerkers bij de start van een project naar een functie in dat project. De afdeling HRM maakt een selectie uit de sollicitatiebrieven, roept medewerkers op voor een gesprek en heeft invloed op de uiteindelijke samenstelling van de teams. Zodra een nieuw team de inwerkfase heeft afgerond, worden er functioneringsgesprekken gehouden. De afdeling HRM geeft aan welke competenties in deze gesprekken per medewerker aan de orde zullen komen. De medewerkers worden hiervan tijdens de inwerkfase op de hoogte gesteld. Iedere medewerker krijgt gedurende het project een medewerker van de afdeling HRM toegewezen als coach. Deze coach is verantwoordelijk voor het voeren van de gesprekken. ICT4Events werkt met een POP, een persoonlijk ontwikkelplan. De coach van HRM is beschikbaar voor medewerkers die advies willen bij het schrijven van hun POP. Deze POP draagt bij aan het benutten van de ontplooiingskansen.

De heer J Boonen is hoofd van de afdeling HRM. Afdeling Administratie De administratie is de spil van ons bedrijf. Interne en externe post verloopt via deze afdeling. De taken van de administratie zijn: Verwerken van inkomende en uitgaande, interne en externe post; Opslaan en verwerken van urenverantwoordingsformulieren; Bijhouden van aanmeldingen voor cursussen; Zorgen voor de uitgifte van ons wekelijks info bulletin. De leiding van deze afdeling is in handen Brenda Lie A Tsoen. Op dit moment zijn wij nog bezig met de invulling van de functie "administratief medewerker". In de volgende paragrafen worden de ontwikkelafdelingen uit het organogram in detail besproken Afdeling Software De afdeling software houdt zich bezig met de nieuwste ontwikkelingen op het gebied van Object Oriented ontwerpen en programmeren. De afdeling maakt vanuit klantspecificaties de vertaalslag naar softwareoplossingen met dotnet. Deze oplossingen variëren van embedded software tot webapplicaties met ASP.net. De focus ligt op software ontwikkeling voor Windowsapplicaties met o.a. MFC en MVC. Hoofd van deze afdeling is de Heer Sjaak Verwaaijen Afdeling Information Management “In-house” ook weleens de afdeling “databases” genoemd. Deze afdeling houdt zich bezig met het organiseren van de opslag van en de toegang tot alle benodigde informatie welke om gaat in de

9

software. Deze afdeling werkt dan ook nauw samen met de afdeling Software. Hoofd van deze afdeling is de Heer T. Broumels. Afdeling Infrastructuur De afdeling infrastructuur zorgt er voor dat de ontwikkelde softwareoplossingen en webapplicaties op het SME door meer mensen tegelijk kunnen worden gebruikt. Daarnaast wordt, in overleg met de opdrachtgever, een oplossing op maat geboden voor een tijdelijke netwerkinfrastructuur op een event. Met de afdeling software en information management wordt samengewerkt om te zorgen dat de applicaties en gegevens zo nodig op afstand beheerd kunnen worden. Hoofd van deze afdeling is de Heer S. Roijers.

Communicatielijnen Een bedrijf werkt goed als er voldoende platforms zijn. Het is immers onmogelijk om alles via e-mail of per telefoon af te handelen. ICT4Events heeft gekozen voor een hiërarchische overlegstructuur zodat het ontwikkelteam zich intensief met het product kan bezig houden en niet bij elk overleg aanwezig hoeft te zijn. Het team communiceert hoofdzakelijk met de productmanager, hij of zij is namelijk eindverantwoordelijk voor het op te leveren product. Dit productgerichte overleg zal na de inwerkperiode iedere week plaatsvinden met de productmanager of een plaatsvervanger. Bovendien heeft een vertegenwoordiger van het ontwikkelteam (projectleider) elke 2 weken een overleg met de projectcoördinator over organisatorische kwesties.

10

Opdrachtbeschrijving Ict4Events heeft de opdracht gekregen om de ICT te verzorgen voor een SocialMediaEvent (SME). Dit is een bijeenkomst van jongeren op een open terrein, waar de digitale communicatie optimaal is geregeld. Ict4Events moet zorgen voor het netwerk, de databases en de applicaties voor reservering en toegangscontrole. Verder op worden de eisen nog toegelicht.

Toelichting SME-Concept Social Media zoals Hyves, Twitter en Facebook zorgen voor allerlei digitale contacten tussen jongeren, maar het is een vaak gehoord verwijt van achterblijvers op de digitale snelweg; “al dat virtuele gecommuniceer staat echt contact met de medemens alleen in de weg!” Waarom niet mensen in levende lijve ontmoeten, juist door het Internet? Dit zie je steeds ook vaker gebeuren. Bijvoorbeeld de flashmobs in grote steden, opeens komen groepen mensen, die elkaar kennen van de socialmedia, bij elkaar om iets ongebruikelijks te doen bijvoorbeeld te zingen of te dansen midden op een plein. Opnames hiervan worden meestal op het Internet geplaatst. Ook is er de “apéro géant” , samen gaan eten en gaan drinken op een originele plek. In Frankrijk zelfs met zo’n duizend mensen. Zelfs Tweakers.net organiseert zijn eerste nietvirtuele gathering voor bezoekers omdat er behoefte aan is. Het SME speelt in op deze behoefte en wil de jongeren bij elkaar brengen om ook fysiek hun ervaringen, ideeën en talenten te delen. Bij dit event worden digitale hulpmiddelen ingezet om het sociale contacten interessanter, mooier en grootser te maken. Zo kunnen er muziek- en video opnamen gemaakt en ge-edit worden. Deze bestanden kunnen dan ook weer door de deelnemers download en geshared worden. Beamers en grote schermen kunnen gebruikt worden om gemaakte digitale producties te laten zien. Discussiërend picknicken gaat met de laptop erbij, zodat ook Google kan meedoen en er worden polls gehouden om meningen te peilen en stemmingen te houden.

SME-concreet Jongeren worden benaderd via de bekende SocialMedia communities om aan het event deel te nemen. Het event wordt gehouden op de camping Valkenhof in Westerbork, zie plattegrond van de camping in bijlage 2 De jongeren komen op de camping met tenten, allerlei digitale apparatuur en kunnen van uit de tent hun computers aan elkaar koppelen. Verder is er een hoofdgebouw waar de catering plaats vindt en de SME- pc-dokter aanwezig is om deelnemers te helpen bij computerstoringen. Verder staan er een aantal PC’s in deze ruimte in een eigen netwerk, met o.a. editsoftware voor video en geluid. In deze tent zijn ook veilige opslagplaatsen voor bijvoorbeeld videocamera’s van de bezoekers. Tenslotte is hier ook de opslag van materiaal dat uitgeleend kan worden.

11

Het is duidelijk dat dit event hoogwaardige ICT-ondersteuning noodzakelijk maakt op het gebied van infrastructuur, database en software. ICT4Events is daarom ook erg blij met deze opdracht. In de eerste uitvoering van het event moet de hele infrastructuur verzorgd zijn, een inschrijvingssysteem beschikbaar zijn, toegangscontrolesysteem aanwezig en een catalogussysteem met filesharing en downloading mogelijk zijn.

Systemen Vanuit de beschrijving van het SME-concept zijn de volgende globale eisen geformuleerd. File sharing: Bezoekers kunnen files beschikbaar stellen om te sharen. Dit zal moeten door het presenteren van catalogus. Het is niet namelijk inzichtelijk welke gebruiker welke files beschikbaar stelt op het event. Men kan hierdoor port scans gaan uitvoeren over het gehele netwerk wat de snelheid van het netwerk niet ten goede komt. Hier moet daarom een goede oplossing d.m.v. een catalogus voor komen. Inschrijven en reserveren van een kampeerplek naar keuze: Bezoekers willen met hun Socialmediavrienden en kennissen fysiek dicht bij elkaar in de buurt en/of op een specifieke locatie van de camping kunnen staan. Dat betekent dat de plaats niet wordt aangewezen op dag één van het evenement, maar dat deze bij inschrijving al kan worden gekozen. Snelle controle van toegangsbewijs en geldigheid van het toegangsbewijs: Bezoekers moeten snel door de controle. Ook als men pas ’n dag van te voren heeft betaald moeten de portiers snel kunnen controleren of er betaald is. Vanuit het overleg van de productmanager met de opdrachtgever is gekomen dat de volgende systemen ontworpen en gebouwd moeten worden. 

Netwerk infrastructuur o Bedraad en draadloos netwerk beschikbaar over het hele terrein. o Afgeschermd netwerk voor servers en specifieke applicaties. o Centrale gateway voor Internet toegang.



Filesharing catalogus o Verschillende mediatypen files o Downloaden files o Sharen files o Oneindig diepe categorieënstructuur. o Informatie van files bijhouden. o Zoeken naar files/categorieën o Gebruikersrechten o Opschoon mogelijkheid o Informatie over files (thumb up/down) o Mogelijk verbinden met Microsoft Active directory



Reserveringssysteem o Boeken reservering voor een groep o Kiezen van kampeerplaats d.m.v. plattegrond 12

o o o o 

Huurmogelijkheid extra materiaal met vastlegging als betaling binnen is Zoekmogelijkheid naar vrije kampeerplaats Speciale reserveringsvakken geven melding. (lawaaiplek, handicap) Uitgeven van RFID polsbandjes

Toegangscontrolesysteem o Gebruikersgroepen o Reservering realtime bekijken (RFID)

In overleg met de opdrachtgever zal de projectgroep deze requirements helder moeten krijgen. Hieronder worden de verschillende systemen nog eens toegelicht vanuit de verschillende vakgebieden.

Infrastructuur Op het SME-terrein moet een infrastructuur worden ingericht met routers, switches, bekabeling en een draadloos netwerk waarop alle deelnemers hun computers en hun eigen spullen kunnen aansluiten. In het hoofdgebouw komt een klein apart netwerkje voor de pc’s waarop de zelfgemaakte applicaties, databases, active directory server etc. draaien. Dit moet beveiligd en afgeschermd worden van de rest van het grote netwerk om te zorgen dat de applicaties goed blijven functioneren. Producten:  Ontwerp van een combinatie van bedraad en wireless netwerk beschikbaar op het hele terrein (fysieke opstelling en logisch ontwerp). Laat op de plattegrond zien waar je welk soort netwerk wil gebruiken en geef aan waar wireless accesspoints zouden moeten komen  Ontwerp en realisatie van een klein afgeschermd netwerk voor de databases, active directory servers en applicatie servers. Het ontwerp bevat een netwerktekening en een goed doordacht IP-plan met slim gekozen subnetten.  Ontwerp en realisatie van een file sharing server waarbij je in staat bent om aan gebruikers rechten toe te kennen op basis van hun gebruikersgroep. Bedenk zelf mogelijke groepen.  Realisatie van een demonetwerk voor een “proof of concept” van bovenstaande producten. Dit demonetwerk bevat alle functionaliteiten waarop de ontwikkelde applicaties kunnen worden getest. Je kunt hiervoor gebruik maken van virtuele machines op jullie studentlaptops. Daarvoor kun je je IN21 machines converteren vanaf ESX met “VMware converter”. Als je voor het demo-netwerk meerdere laptops met elkaar wil verbinden kun je een netwerkswitch lenen bij de ISSD.

Databases Gegevens moeten worden op een dusdanige manier worden opgeslagen dat deze niet op de een of andere manier kwijt raken of corrupt worden. Ook moeten de gegevens op een efficiënte manier benaderd en gemuteerd kunnen worden. Dit kan worden bereikt door voorafgaand een goed ontwerp van de database(s) te realiseren in samenwerking met de afdeling software alvorens de database te realiseren. 13

Tip: maak slim gebruik van de technieken uit de databases vakken om aan de gestelde eisen te voldoen. Naast ontwerpen en scripts voor het aanmaken (en eventueel vullen met testdata) van de databases moet de degelijkheid van het ontwerp worden aangetoond. Dit laatste is een belangrijke eis van de kwaliteitsmanager.

Software Voor het SME moeten verschillende soorten applicaties gemaakt worden, zie de beschrijving van de systemen hierboven. Al deze applicaties gaan gebruik maken van de door de afdeling Information management ontworpen databases. De projectgroep gaat deze applicaties parallel ontwikkelen wat natuurlijk een complex gebeuren is. Het maken van goede user requirements documenten (URS) is hierbij een belangrijk vereiste, hierin moet ook duidelijk aangegeven worden wat de prioriteiten zijn van de verschillende functionaliteiten, dit moet afgestemd worden met de productmanager. De software moet op een zodanige manier gemaakt worden dat deze eenvoudig uit te breiden is met nieuwe functionaliteiten en bestaat uit onderdelen (klassen) die eenvoudig herbruikbaar zijn in andere projecten. Bovenstaande randvoorwaarden hebben tot gevolg dat de volgende eisen aan de software gesteld gaan worden: 1. 2. 3. 4. 5. 6.

De specificaties in het URS worden met behulp van usecases en scenario’s beschreven De ontwerpen worden in UML gemaakt. De applicatie is op een correct object georiënteerd manier ontworpen. De code is voorzien van commentaar. Er worden logische namen gebruikt voor de verschillende onderdelen. Wijzigingen in de software worden ook in de documentatie verwerkt.

De projectgroep maakt gebruik van een RFID systeem, deze kan o.a. gebruikt worden voor toegangscontrole, reserveren en ophalen van spullen, en betalingen op het terrein.

Testen Tijdens het ontwikkelproces van een softwaresysteem kunnen allerlei soorten testen worden uitgevoerd. In dit project doen we ’n soort acceptatietest. Een soort, want een acceptatietest is veel uitgebreider dan wat wij doen. De testsoort is een zogenaamde black-box test en is gebaseerd op de functionele eisen. Er wordt beoordeeld vanuit de kennis van wat het systeem moet doen, alleen de buitenkant is van belang. Black-box test bieden de ontwikkelaar inzicht in de kwaliteit van het systeem dat ter acceptatie wordt aangeboden en zij informeren de opdrachtgever, gebruiker en beheerder over de mate waarin aan de opdracht is voldaan en het systeem in productie kan worden genomen. De acceptatietest is een door de gebruiker(s) en beheerder(s) in een zoveel mogelijk als-ware-hetproductie-omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem aan de functionele en kwalitatieve eisen voldoet. Na het opstellen van de functionele specificaties kunnen al de testcases worden opgesteld.

14

Overige eisen Ict4Events maakt al zijn applicatie in C# m.b.v. VisualStudio dus ook de applicaties voor dit event.

Hulpmiddelen. Via de ISSD zijn switches, WLAN access points, RFID-tags en andere hardware te leen.

15

Bedrijf versus School Hoe goed we ook een bedrijfssituatie nabootsen er moet altijd een link naar het onderwijs worden gemaakt. In dit hoofdstuk wordt toegelicht hoe de relatie is gemaakt.

Rollen De proftaak is een nabootsing van een praktijksituatie. Veel onduidelijkheden laten zich eenvoudig oplossen door vanuit de praktijk naar een rol te kijken. Houd er dus steeds rekening mee in welke rol je iemand aanspreekt. Hieronder zie je met wie je als junior software engineer van ICT4Events (student) communiceert binnen de proftaak en hoe die rol wordt ingevuld. Wie

Wat

Hoe

Wanneer

Vakeigenaar proftaak

Projectencoördinator

Bespreekt de organisatorische aspecten met de projectleiders.

2 Wekelijks overleg

Vakdocent/eigenaar DB,SE,INFRA

Consultant

Begeleidt op inhoudelijke kennis en vaardigheden

Tijdens les/afspraak

Tutor/projectbegeleider

Productmanager

Volgens rooster of op afspraak

Studieloopbaanbegeleider

HRM

Beoordeellaar

Productmanager

CE of PiE

Opdrachtgever

Prodrive

Reviewer

Bewaakt de functionaliteit. Communiceert met opdrachtgever. Begeleidt afstandelijk procesmatig en inhoudelijk het ontwikkelteam. Ondersteunt het ontwikkelproces van het individuele lid van de projectgroep Beoordeelt de producten bij de opleveringen en het proces gedurende het project. Stelt de eisen en krijgt tussentijdse rapportages Review van het ontwerpdocument

Volgens rooster of op afspraak Tijdens opleveringen/ beoordelingen Op afspraak week 1 of 2 Op afspraak week 4 of 5

Consultant Een consultant inschakelen kost tijd en geld. Maar zorg dat je minimaal feedback krijgt op je ERD, infrastructuurdiagram en op het klassendiagram. Deze feedback wordt gedocumenteerd en gecommuniceerd met de productmanager. Opdrachtgever De opdrachtgever voor ICT4Events is slechts beperkt aanspreekbaar. Hij heeft weinig tijd en zit veel in het buitenland. Toch zul je in de beginweken van het project (week 1 of 2) een gesprek moeten regelen om de opdracht helder te krijgen en onduidelijkheden weg te nemen. Later in het project zal de opdrachtgever graag op de hoogte gehouden willen worden van de voortgang d.m.v. een update via email. Het gesprek wordt gedocumenteerd en gecommuniceerd met de productmanager. Prodrive Het is belangrijk dat onze proftaken overeenkomen met opdrachten die in de praktijk voorkomen. Maar vooral ook dat de uitwerkingen voldoen aan de eisen die in het bedrijfsleven gangbaar zijn. 16

Daarom zullen software engineers van het bedrijf Prodrive ( http://www.prodrive.nl/ )jullie ontwerpdocumenten reviewen. Dit zal in week 4/5 gebeuren in een sessie van c.a. 1 uur bij het bedrijf. Tijdens deze sessie wordt jullie ontwerpdocument besproken en maken jullie een verslag dat zij aan het eind van de sessie ondertekenen. Dit verslag lever je in bij de productmanager. Procedure: 

  

Zend het URS na goedkeuring van de productmanager op naar: [email protected] dit is in week 2/3 en maak een afspraak voor de review van het ontwerpdocument. Deze review is in week 4/5 Zend het ontwerpdocument minimaal 3 werkdagen voor de afspraak naar [email protected]. Lever het ondertekende verslag van de review in bij je productmanager. Secretaris documenteert het reviewverslag

Studentrollen binnen het project Een projectgroep bestaat uit 5 á 6 personen die verschillende rollen in het project kunnen vervullen, maar daarbij is ieder projectlid wel goed op de hoogte van de werkzaamheden van de andere rollen. We onderscheiden: 



  

Projectleider: is de trekker van het project, heeft overzicht, verdeelt taken, stemt deze op elkaar af, stelt actiepunten vast, controleert de voortgang en stelt indien nodig de planning bij. Secretaris: Houdt het projectdossier bij, is verantwoordelijk voor de documentatie van het project. De gespreksverslagen met o.a. opdrachtgever, consultant en Prodrive moet hij/zij dus goed documenteren. Rapporteur: Is eindredacteur van de eindrapportage, verzorgt de eindpresentatie, koppelt terug op gestelde doelstellingen. Kwaliteits manager: is de eindverantwoordelijke als het gaat om kwaliteit van de in het project opgeleverde producten (documentatie, software sources, …). Projectlid: Werkt inhoudelijk mee aan alle projectactiviteiten volgens planning afgesproken werkzaamheden, schrijft aan het eind van het project een stuk zelfreflectie over het functioneren binnen het team. Ieder groepslid vervult ook de rol van projectlid.

Per week rouleren de volgende rollen:  

Voorzitter: Opent bij de bijeenkomst de vergadering. Licht de agenda toe, stelt tijdschema voor, leidt het gesprek. Notulist: Noteert tijdens de bijeenkomst de belangrijkste redeneringen/argumenten en de besluiten, zorgt ervoor dat één dag voorafgaand aan de bijeenkomst agenda en vergaderstukken in ieders bezit zijn.

De invulling van deze rollen moet volgens de richtlijnen van Beroepsvaardigheden. Groepsleden zijn op de projectdag van 9.00 – 17.00 uur aanwezig.

17

18

Fasering en producten In dit hoofdstuk wordt uitgelegd hoe de organisatie rond de proftaak geregeld is. Omdat de proftaak een nabootsing van de praktijk is, staat in dit hoofdstuk een aantal zaken uitgelegd zoals je ze in de praktijk ook ziet. Een software ontwikkelproces kan ingedeeld worden in een aantal fases. In elke fase worden een aantal producten opgeleverd. Er zijn allerlei soorten faseringen mogelijk, wij kiezen bij deze proftaak voor een eenvoudig verdeling in 4 fasen.

Inwerkfase In deze fase wordt het project opgestart en domeinkennis opgedaan. Dit wil zeggen teamafspraken worden gemaakt om het team goed te laten functioneren. Hierbij moet je denken aan reglementen, activiteitenlijsten, rolverdelingen, ingericht documentenbeheer en software omgeving inrichting. Al bij de eerste bijeenkomst zal een eerste globale planning moeten worden gemaakt met activiteiten, producten en opleveringstijdstippen. Verder zal in deze fase ieder teamlid voldoende kennis moeten verkrijgen om de systemen te kunnen maken. Hiervoor zijn natuurlijk de lessen op het gebied van programmeren, databases en infrastructuur van belang. Maar de groep zal zeker ook zelf onderzoek moeten uitvoeren en dat aan elkaar moeten rapporteren. Ook zal in deze fase ELK teamlid zich het domeinmodel van de systemen eigen moeten maken. Dat zal moeten gebeuren door een degelijke analyse welke leidt tot een URS (zie bijlage). Hiervoor zal o.a. de opdrachtgever geïnterviewd moeten worden. Het URS zal volledig begrepen en geaccepteerd moeten worden voordat het team een PID kan gaan opstellen voor de volgende fase van het ontwikkeltraject. Het team zal een PID moeten maken volgens de richtlijnen geleerd in het vak Beroepsvaardigheden (BV) en bevat o.a. de noodzakelijke geplande activiteiten om tot een werkende applicatie te komen die voldoet aan de requirements, zoals in het URS is opgesteld. De producten van deze fase zijn daarom het URS en het PID. De productmanager zal feedback geven op de conceptversie. In deze fase of in de volgende fase moet de groepsleden een peerassessment houden en deze informatie aan HRM en de productmanager aanleveren. Het URS wordt opgestuurd naar Prodrive.

Ontwerpfase In deze fase wordt het product ontworpen op de wijze die met de productmanager overeengekomen is (URS). Hiervoor zullen de databaseontwerpen, de infrastructuurontwerpen, de softwareontwerpen en de gedetailleerde UIontwerpen moeten worden gemaakt. Deze producten komen in één ontwerpdocument en de productmanager zal feedback geven op de conceptversie. Verder zal een er review worden gegeven op de ontwerpen door Prodrive. Hiervoor moet er een afspraak worden gemaakt met J. Mandemaker. Zie de beschreven procedure hierboven.

Bouwfase In deze fase worden de verschillende deelapplicaties ontwikkeld volgens de afspraken in het URS en volgens de ontwerpen in het ontwerpdocument. De kwaliteit van de code moet voldoen aan de gestelde eisen van het bedrijf.

19

Afrondingfase Tenslotte vindt de oplevering van het systeem aan de productmanager en opdrachtgever plaats. De groep demonstreert de functionaliteit van het systeem, beantwoordt de vragen en licht onduidelijkheden toe. De groep laat ook zien dat ze gebouwd hebben wat de opdrachtgever heeft gevraagd en dat de applicaties voldoen aan de vereiste kwaliteit, d.w.z. de programma’s werken correct, zijn robuust en zijn begrijpelijk. Verder is de code eenvoudig uitbreidbaar en ook herbruikbaar. De acceptatietest wordt ook in deze fase uitgevoerd. Antwoorden waarop bij deze test gegeven moeten worden:   

kan het systeem in productie en beheer worden genomen? Welke risico’s worden daarbij genomen? Hebben we aan onze verplichtingen voldaan?

Beoordeling De studiebelasting van deze proftaak is 84 SBU (= 3 EC’s studiepunten). Tijdens de proftaak wordt gewerkt aan alle competenties. Zie o.a. het blokboek. De proftaak valt in 3 beroepsproducten uiteen die een afzonderlijk beoordelingsresultaat opleveren, dit zijn de User Requirements Specification, het Eindproduct en de Uitvoering. Deze beroepsproducten worden op een DVD ter beoordeling opgeleverd. Deze DVD moet op de vrijdag in de week vóór de oplevering in het bezit zijn van de productmanager. Anders kan de oplevering NIET doorgaan. Het spreekt voor zich dat deze DVD compleet, verzorgd en overzichtelijk is. URS De URS is een document wat duidelijk moet maken wat de klant wil dat er gebouwd gaat worden. Alle betrokkenen van het project moeten uit dit document kunnen afleiden wat het systeem behelst. In het document moeten daarom de eisen en de functionaliteit helder, compleet en eenduidig beschreven zijn. Voor het URS-document is een template beschikbaar in de bijlage. Eindproduct In deze proftaak werk je aan 3 verschillende deelproducten, die samen tot de realisatie van het eindproduct leiden. Deze deelproducten moeten voldoende zijn beoordeeld om het eindproduct voldoende beoordeeld te krijgen Eindproduct Ontwerpdocument Applicaties Acceptatietest

20

Ontwerpdocument Zoals eerder aangegeven bevat het ontwerpdocument de ontwerpen van databases, infrastructuur, software en GUI. Deze ontwerpen zijn gemaakt volgens de methoden en technieken zoals geleerd bij de respectievelijke vakken. Het gaat hier om een echt document en niet om een verzameling ontwerpen. Dus de opbouw van het document voldoet aan de eisen van de FHICT en de ontwerpen worden textueel toegelicht. De ontwerpen worden gereviewd door Prodrive. Deze review wordt verwerkt in dit document. Applicaties De applicaties voldoen aan de functionaliteit zoals in het URS is gesteld en voldoen bovendien aan de kwaliteitseisen zoals toegelicht in de paragraaf kwaliteit. De applicaties bevatten helpfuncties en uitleg voor de gebruiker. De applicaties worden op DVD opgeleverd z.d.d. de beoordelaar de code kan bekijken en eenvoudig de applicaties kan draaien. D.w.z. ook de Database moet gebruikt kunnen worden. Acceptatietest Jullie voeren een functionele applicatietest uit. Deze is dus zuiver gebaseerd op de functionele eisen uit het URS. De opzet, uitvoering en resultaten van de tests moeten worden gecommuniceerd via het acceptatietestdocument. Hierin staat welke, waarop, wanneer en hoe de tests zijn uitgevoerd en natuurlijk wat de resultaten en de conclusie van de tests zijn. De beoordeling is niet het resultaat van de tests maar hoe de tests zijn opgezet, uitgevoerd en gedocumenteerd. De layout van dit document is te vinden in bijlage 4. De uitvoering De uitvoering is een individuele beoordeling van het proces van een groepslid d.m.v. gedragsindicatoren. Een project van deze omvang leidt alleen tot een goed eindproduct als het proces binnen de groep goed verloopt. Of het groepsproces goed verloopt, hangt af van de individuele leden van de projectgroep. De beoordeling door de tutor is gebaseerd op de groepsbijeenkomsten, reflecties, presentaties en peerassessments. De criteria die hierbij worden gehanteerd zijn:   

Houden van afspraken (product en aanwezigheid) Actief deelnemen aan overleggen en besprekingen (commitment/inzet/initiatief) Geven en ontvangen van feedback (zie ook beroepsvaardigheden)

21

Oplevering Er zijn bij deze proftaak 3 soorten opleveringen. Allereerst de interne bedrijfsoplevering, dan de oplevering voor de opdrachtgever en tenslotte de oplevering voor de school.

Interne oplevering Bij de afronding voor ICT4Events geef je een korte demo aan de productmanagers van het bedrijf. Doel van deze demo is dat het duidelijk is hoe de applicatie werkt en of deze voldoet aan de kwaliteitseisen van ICT4Events. De groep zal bij deze bijeenkomst ondervraagd worden door de productmanagers.

Oplevering aan opdrachtgever Het uitrollen van de applicatie bij de klant gebeurt door de buitendienst. De projectgroep moet nog wel een afsluitend bericht sturen naar de opdrachtgever.

Oplevering voor school De oplevering voor school bestaat uit 3 delen:   

DVD op tijd en compleet bij de productmanager Demo en ondervraging tijdens interne oplevering Individuele beoordelings en feedback gesprek met de tutor over de 3 beroepsproducten.

Opleveringsessie:    

Demo door groep 10 minuten Vragen ter verduidelijk aan groep 10 minuten Overleg docenten c.a. 5 minuten Individuele beoordelings en feedback gesprek 5 min/student

Kwaliteitszorg Kwaliteit is een zeer belangrijk aspect bij software ontwikkeling. Software krijgt een goede kwaliteit door het gebruik van de juiste middelen en door een professionele attitude van de ontwikkelaars zodat het proces goed verloopt. Iedereen heeft wel een idee wat goede software is, -

de applicatie moet doen waarvoor het gemaakt is (correct), niet crashen (robuust), code moet helder zijn (begrijpelijk), nieuwe functionaliteit moet eenvoudig worden toegevoegd (uitbreidbaarheid), stukken code kunnen ook in andere applicaties worden gebruikt (herbruikbaar) en het programma moet snel zijn (efficiënt)

Voldoet de software hieraan dan heb je een kwalitatief goed product. Het is belangrijk dat de kwaliteitsmanager van de groep alert is op deze eisen en de relatie tussen ontwerp, use cases, testen en klassen goed in de gaten houd. Zie als voorbeeld om dit in de gaten te houden bijlage 3. 22

Om de kwaliteit te borgen zijn de reviewsessies van prodrive van belang.

Tools Tools dragen bij tot de kwaliteitsverhoging van de software. Wij gebruiken daarom Microsoft Visual Studio zodat een software engineer op allerlei manieren wordt geholpen bij de ontwikkeling van het product. Omdat een goede tool nog niet de garantie is voor goede kwaliteit, zul je bij de lessen leren hoe je met behulp van methoden, technieken en de tools tot een kwalitatief goed product kunt komen. Belangrijk hierbij is ook dat je je aan de afgesproken conventies houdt zoals naamgeving van variabelen en commentaar bij de code. Natuurlijk is het correct gebruik van schematechnieken ook van groot belang. Gebruik van Oracle en SVN van buiten het Fontys netwerk Vanuit C# code de Oracle server benaderen vanuit buiten het Fontys netwerk is niet mogelijk. Dit omdat het bereikbaar maken van de Oracle server het voor kwaadwillenden van buiten het Fontys netwerk mogelijk maakt om aanvallen uit te voeren op deze server. Dat willen we natuurlijk niet. Als alternatief kan je lokaal op je ontwikkel systeem (je laptop) de gratis Oracle variant installeren en deze vanuit je code benaderen. SVN is wel van buiten het Fontys netwerk te benaderen. Dit omdat SVN verbindingen beveilgd worden opgezet.

Testen Testen is ook een instrument dat een bijdrage levert in het streven de kwaliteit van software te verbeteren. Testen hoort ook bij de kwaliteitszorg van een organisatie. In deze periode maken we een begin met testen en het meest voor de hand ligt het dynamisch uitvoeren van gerichte testgevallen, het draaien van programma’s. Daarbij wordt het actuele resultaat vergeleken met het verwachte resultaat om zo te bepalen of het systeem zich als vereist gedraagt. Tegelijk wordt dan ook duidelijk hoe het systeem zich gedraagt qua snelheid, storingen of zelfs crashes. Ook wordt de gebruikersvriendelijkheid van het systeem tijdens zo’n test duidelijker.

Professionalisering De proftaak onderscheidt zich van een practicumopdracht door de context waarin de opdracht uitgevoerd wordt. Een proftaak gaat over de werkelijkheid, terwijl in een practicum de opdracht uit de context gehaald is en alleen uitgevoerd wordt om jezelf te trainen. Alle groepsleden moeten aan alle onderdelen van de proftaak hun bijdrage leveren. De taakverdeling mag dus niet zo ver gaan dat groepsleden los van elkaar delen van het project uitvoeren. Het gaat erom dat je als individu het geheel beheerst.

Vastleggen afspraken Alle afspraken tijdens de proftaak moeten worden vastgelegd; mondelinge afspraken hebben geen geldigheid. Dus alle uitnodigingen, evaluaties, verslagen, etc. worden schriftelijk uitgevoerd. De groepsleden mogen elkaar op gemaakte afspraken wijzen. Alle documenten worden systematisch gestructureerd geplaatst zodat ze voor iedereen toegankelijk zijn. 23

In een professioneel werkend ontwikkelteam ben je afhankelijk van ieders inbreng. Er moet voldoende worden samengewerkt om tot een kwalitatief goed eindproduct te komen. Verslaglegging is daarbij niet alleen van essentieel belang voor de voortgang tijdens het werken in teamverband, maar ook voor degenen die in de toekomst verder moeten werken aan het product. In deze proftaak werk je met een externe opdrachtgever, die wil weten welke werkzaamheden grote kosten met zich meebrengen. Sommige werkzaamheden zijn eenmalig, maar andere taken zullen ook na oplevering van het product steeds opnieuw moeten plaatsvinden. Om de opdrachtgever een goed kostenoverzicht te kunnen geven, krijgen alle teams de opdracht om gedurende het hele project tijd te schrijven. Bij het tijdschrijven moet, zoals gewoon in een professionele organisatie, onderscheid gemaakt worden tussen 2 categorieën: -

Tijd per onderwerp per teamlid besteed aan de eigen ontwikkeling: niet-declareerbare tijd Tijd per taak per teamlid besteed aan eenmalige taken.

Het team draagt er zorg voor dat een overzichtelijk verslag wordt gepubliceerd op de werkgroep.

24

Bijlage 1: User Requirements Specification (Document van Eisen) Een mogelijk format voor dit document is : 1. Inleiding De inleiding bevat minimaal een korte introductie van dit document en een globale beschrijving van het te ontwikkelen product. 2. Begrippen Toelichting op de gebruikte begrippen in dit document. 3. Functionele eisen Een overzicht wordt gegeven van alle eisen, gegroepeerd in welke eisen zeker geimplementeerd worden, en welke mogelijk geimplementeerd worden (op aflopende prioriteit). Neem ook op welke eisen zeker niet geimplementeerd worden. Van iedere te bouwen functie wordt met behulp van een USE-case aangegeven wat de functie inhoudt. Per use case dienen ook enkele scenario's beschreven te worden die gebruikt worden om de applicatie te testen.

4. User interface In dit gedeelte wordt de eerst de user-interface globaal beschreven, werken we met menu-schermen, is de applicatie event-gestuurd, .... Vervolgens wordt van iedere systeemfunctie aangegeven, hoe deze door de gebruiker geactiveerd kan worden en hoe de verdere afhandeling gaat. 5. Niet-functionele eisen In dit gedeelte worden die eisen beschreven, die niet direct te koppelen zijn aan een bepaalde functie. Dit kan variëren van de eisen die gesteld worden aan de te gebruiken hardware tot bv. algemene eisen over de performance van het systeem.

25

Bijlage 2: Plattegrond Camping

26

Bijlage3: Koppeling URS-Klasse-Test URS ursid

UC requirement

type

uc-id

use case

klasse

Method

test-id

ov-1

user moet inloggen op applicatie

functioneel

ov1uc1

inloggen gebruiker

frmLogin

Login

ov1uc1ft1

frmLogin

Login

ov1uc1ft2

frmLogin

Login

ov1uc1ft3

ov-2

user moet uitloggen op applicatie

functioneel

ov-3

delen van stad moet nabouwbaar zijn

overig

fun-1

plaatsing wegdelen in matrix

functioneel

ov1uc2

ontwerp

Test

uitloggen gebruiker

27

test

inloggen bekende gebruiker, verkeerde pwd inloggen bekende gebruiker, juiste pwd inloggen onbekende gebruiker

type

functioneel functioneel functioneel

Bijlage 4: Acceptatietestdocument layout Inleiding Aanleiding voor de acceptatietest Doelstelling van de acceptatietest Acceptatiecriteria Opzet Aanpak (hoe) Omgeving (waarop) Testcases (welke) Testschema (wie,wat, wanneer) Resultaten Output Testbeoordelingen Conclusie Advies

28