CMDB Applicatie
Productverslag
Door : Eric van Haperen Studentnummer : 2005033 Kenmerk : Productverslag Datum : 11 augustus 2010
1.1 6 augustus 2010 Diverse aanpassingen feedback collega’s 1.2 11 augustus 2010 Diverse aanpassingen feedback Erco Argante
Inhoud
Dit productverslag bevat de volgende documenten: Plan van Aanpak
Onderzoek Ontwikkelmethodes Haalbaarheids- en bedrijfsonderzoek Functioneel Model
Systeemontwerp en –bouw
CMDB Applicatie
Plan van Aanpak
Door : Eric van Haperen Studentnummer : 2005033
Kenmerk : PvA
Datum : 11 augustus 2010
Automotive IT Services B.V. Plan van Aanpak
1.0 11 april 2010 Spelfouten gecorrigeerd
1.1 19 april 2010 Kleine wijzigingen in hoofdstuk Kwaliteit
1.2 3 mei 2010 Aanpassing planning op basis van iteraties en prototyping 1.3 16 mei 2010 Verwerking feedback Erco Argante
1.4 26 juni 2010 Aanpassing planning
1.5 6 augustus 2010 Diverse aanpassingen feedback collega’s 1.6 11 augustus 2010 Diverse aanpassingen feedback Erco Argante
Automotive IT Services B.V. Plan van Aanpak
2. Achtergronden 7 2.1 Algemeen 7 3. Probleem- en doelstelling 8 3.1 Probleemstelling 8 3.2 Doelstelling 8 4. De projectopdracht 9 4.1 Opdrachtformulering 9 4.2 Opdrachtgever en opdrachtnemer 9 5. Projectactiviteiten 10
5.1 Projectactiviteiten Avans Hogeschool 10
5.2 Projectactiviteiten AmITS 10
6. Projectgrenzen 11
7. De producten 12
7.1 Producten Avans Hogeschool 12
7.2 Producten AmITS 12 8. Kwaliteit 13 9. De projectorganisatie 14 10. Planning 15 11. Kosten en baten 16 11.1 Kosten 16 11.2 Baten 16 12. Risico´s 17 13. Bronnen 18
1. Inleiding
Om te kunnen afstuderen voor de deeltijdopleiding Informatica, welke ik volg bij Avans Hogeschool, moet ik bij mijn werkgever een afstudeeropdracht uitvoeren in de vorm van een project. Middels dit Plan van Aanpak wil ik een indruk geven van het bedrijf waar de opdracht uitgevoerd zal worden, evenals een overzichtelijke toelichting geven over de opzet van het project.
In hoofdstuk 2 is een globale omschrijving te vinden van het bedrijf Automotive IT Services B.V. en Rüttchen Holding B.V., de overkoepelende organisatie van de Rüttchen-bedrijven. De probleemstelling binnen het bedrijf en de projectopdracht welke hierop gebaseerd is, staan in respectievelijk hoofdstuk 3 en 4. De projectactiviteiten behorende bij de afstudeeropdracht staan in hoofdstuk 5. De activiteiten zijn hierin onderverdeeld in verschillende fasen. Hoe de grenzen waarbinnen het project valt zijn afgebakend staat in hoofdstuk 6. De op te leveren producten en de kwaliteitseisen waaraan deze producten moeten voldoen staan in respectievelijk hoofdstuk 7 en 8. De projectorganisatie staat in hoofdstuk 9. Een globale planning van de uit te voeren activiteiten van de afstudeeropdracht worden weergegeven in hoofdstuk 10. Vervolgens zal in hoofdstuk 11 worden beschreven welke kosten en baten betrekking hebben op het project, waarna in hoofdstuk 12 een overzicht gegeven wordt van risico’s die gelopen worden met betrekking tot de uitvoering van het project. Tenslotte staat in hoofdstuk 13 een literatuurlijst.
2. Achtergronden
2.1 Algemeen
Rüttchen is een van de grotere officiële Mercedes-Benz, Smart en Chrysler dealers van Nederland. Binnen de automotive branche is Rüttchen actief in de divisies personenwagens, bestelwagens en vrachtwagens. Rüttchen is officieel dealer voor de merken Mercedes-Benz, Smart, Chrysler, Jeep Dodge, Honda en Mitsubishi. Inmiddels heeft de organisatie 10 vestigingen. In totaal heeft men +/-450 medewerkers in dienst. De ambitie van Rüttchen is om op korte termijn tot één van de meest toonaangevende dealerbedrijven behoren, vanuit het perspectief van bestaande (en nieuwe) klanten, leveranciers, medewerkers en aandeelhouders.
Naast verkoop en onderhoud aan auto’s is Rüttchen zich ook bezig gaan houden met het concept “full service”. Hiermee willen zij bereiken dat klanten alles wat met auto’s te maken heeft bij Rüttchen kunnen krijgen, hieronder valt bijvoorbeeld Truck- & carcleaning, schadeherstel, carrosseriebouw, verzekeringen, financiering en leasing en verlengde garantie.
De IT-afdeling van Rüttchen handelt onder de bedrijfsnaam Automotive IT Services B.V. als een onderdeel van de Rüttchen Holding B.V.. Automotive IT Services B.V., afgekort AmITS, bestaat uit een directeur, een afdeling Beheer en een afdeling Ontwikkeling. De afdeling Ontwikkeling houdt zich bezig met de ontwikkeling van het eigen Dealer Management Systeem (ERP-pakket) genaamd ADIS (AutoDealer InformatieSysteem). Het pakket wordt ook gebruikt door enkele collega-dealers. De afdeling beheer verzorgt het beheer van het pakket voor Rüttchen en de andere dealerbedrijven op basis van SLA’s. Ook implementeren zij wijzigingen van ADIS in de productieomgeving. Daarnaast is de afdeling Beheer verantwoordelijk voor de gehele IT-infrastructuur van de Rüttchen-bedrijven.
Figuur 1: Het pand aan de Ettensebaan in Breda. Hierin zijn Rüttchen Personenwagens Breda, Rüttchen Holding en Automotive IT Services gevestigd.
3. Probleem- en doelstelling
3.1 Probleemstelling
Onder de verschillende werkzaamheden van de afdeling Beheer van AmITS behoord onder andere de registratie van hard- en software welke is opgenomen binnen de IT-infrastructuur. Ook moet worden bijgehouden welke hardware op voorraad aanwezig is en wanneer en aan wie deze worden uitgegeven. Dit in verband met doorbelasting van kosten aan de desbetreffende vestiging.
Regelmatig komt het voor dat de directeur van AmITS overzichten van de huidig operationeel zijnde hardware vraagt bij de afdeling Beheer ten behoeve van bijvoorbeeld verzekeringen. Ook wordt periodiek bekeken in het kader van licentiebeheer welke software er in omloop is.
Bovenstaande zaken leveren regelmatig problemen op bij de afdeling beheer. Geregistreerde gegevens van hard- en software zijn vaak onvolledig. De gegevens, welke geregistreerd worden in een spreadsheetbestand, vormen daarnaast ook een onsamenhangend geheel. De directeur wil graag een registratie waarin duidelijk zichtbaar is welke hard- en softwarecomponenten direct aan elkaar gerelateerd zijn.
Documentatie van de afdeling Beheer wordt nu opgeslagen op een fileshare. Echter levert het vinden van juiste en recente documentatie op deze manier soms problemen op.
Ook bestaat er geen duidelijk en centraal overzicht van de aanwezige softwarelicenties.
3.2 Doelstelling
De doelstelling van de opdracht is om een softwareapplicatie te ontwerpen en te bouwen welke een oplossing zal bieden op de problematiek zoals beschreven in de bovenstaande probleemstelling.
4. De projectopdracht
4.1 Opdrachtformulering
De afstudeeropdracht bestaat uit het ontwerpen en ontwikkelen van een softwareapplicatie waarmee registratie van hard- en software op een eenvoudige en bovendien snelle wijze uitgevoerd kan worden. Ook dienen op eenvoudige wijze verschillende rapporten uitgedraaid en geëxporteerd te kunnen worden waarin ook de directe relatie tussen hard- en softwarecomponenten zichtbaar moeten zijn. Daarnaast moet er bijgehouden kunnen worden welke hardware er op voorraad is en wanneer en aan welke vestiging deze uitgeleverd wordt. Ook moet er documentatie beheerd kunnen worden binnen het informatiesysteem. Hieronder vallen handleidingen, documenten m.b.t. procedures van de afdeling Beheer en SLA’s. Deze informatie moet snel gevonden kunnen worden middels een zoeksysteem binnen de applicatie.
Om het eindproduct te kunnen ontwerpen en te realiseren zal er vooraf onderzocht moeten worden hoe men dit binnen AmITS anders zou willen gaan doen.
De applicatie zal ontwikkeld worden in J2EE in combinatie met JSP. Reden voor de keuze van J2EE/JSP is dat er reeds meerdere J2EE webapplicaties bij Rüttchen in gebruik zijn welke draaien op meerdere eigen IBM WebSphere Application Servers. Indien dit platform gebruikt kan worden voor de te ontwikkelen applicatie, dan hoeft er niet meer geïnvesteerd te worden in nieuwe hardware en softwarelicenties. Bovendien is er reeds kennis van J2EE aanwezig binnen het bedrijf.
4.2 Opdrachtgever en opdrachtnemer
Opdrachtgever: Pie Rüttchen, Directeur Automotive IT services B.V. Opdrachtnemer: Eric van Haperen
5. Projectactiviteiten
Er kan bij de afstudeeropdracht onderscheid gemaakt worden tussen projectactiviteiten ten behoeve van Avans Hogeschool en projectactiviteiten ten behoeven van AmITS.
5.1 Projectactiviteiten Avans Hogeschool
De projectactiviteiten ten behoeve van Avans Hogeschool zijn: Het schrijven van een projectvoorstel;
Het schrijven van een plan van aanpak;
Het schrijven van een proces- en productverslag; Presenteren en verdediging van de afstudeeropdracht.
5.2 Projectactiviteiten AmITS
De projectactiviteiten ten behoeve van AmITS zijn:
Onderzoek doen naar geschikte ontwikkelmethodes en het maken van een keuze hierin; Onderzoek doen naar bestaande CMDB applicaties;
Onderzoek doen naar EGL.
Doorlopen van verschillende fasen van de gekozen ontwikkelmethode. Hiertoe behoren de activiteiten:
o Het schrijven van rapportages behorende bij de gekozen softwareontwikkelmethode;
o Ontwerpen van de applicatie; o Bouwen van de applicatie.
6. Projectgrenzen
Om achteraf misverstanden te voorkomen over wat wel en niet binnen het project valt, wordt hieronder een overzicht gegeven van de scope van het project. Er zijn ook enkele randvoorwaarden omschreven welke noodzakelijk zijn voor het kunnen slagen van het project.
De scope van het project beslaat:
Het maken, opleveren en uitvoeren van de producten en presentatie voor Avans Hogeschool welke gerelateerd zijn aan de afstudeeropdracht1;
Het maken van rapportages voor AmITS welke gerelateerd zijn aan de afstudeeropdracht2;
Het ontwerpen van de applicatie; Het bouwen van de applicatie; Het testen van de applicatie.
Het maken van gebruikersdocumentatie en helpfuncties; Wat buiten het project valt:
De implementatie van de applicatie; Randvoorwaarden:
Er zijn interne medewerkers van AmITS beschikbaar om betrokken te worden bij het project;
Er zijn hulpmiddelen beschikbaar in de vorm van een pc en de benodigde software voor de ontwikkeling van de applicatie;
Er zal voldoende tijd beschikbaar gesteld worden door de opdrachtgever aan de opdrachtnemer om de opdracht uit te kunnen voeren.
1 Zie het volgend hoofdstuk voor een overzicht van de op te leveren producten aan Avans Hogeschool 2 Zie het volgend hoofdstuk voor een overzicht van de op te leveren rapportages aan AmITS
7. De producten
Er zullen zowel producten opgeleverd gaan worden bij Avans Hogeschool als bij AmITS. Deze worden hieronder beschreven.
7.1 Producten Avans Hogeschool
De volgende producten worden opgeleverd aan Avans Hogeschool: Procesverslag
Het procesverslag beschrijft hoe het uitvoeren van de afstudeeropdracht is verlopen.
Productverslag
Het productverslag geeft een neerslag van de op te leveren applicatie. Presentatie
Er zal een presentatie worden gegeven met bijbehorende verdediging voor een afstudeerpanel bestaande uit de docentbegeleider en een 2e docent.
7.2 Producten AmITS
De volgende producten zullen worden opgeleverd aan AmITS3:
Plan van Aanpak
Met behulp van het Plan van Aanpak is het mogelijk om een goed zicht te behouden op het verloop van het project. Er wordt onder andere beschreven welke producten opgeleverd moeten worden en wanneer
Rapportage(s) t.b.v. vooronderzoek:
- rapportage Onderzoek Software Ontwikkelmethodes - rapportage Haalbaarheids- en Bedrijfsonderzoek (DSDM) Rapportage(s) t.b.v. het ontwerp van de applicatie:
- Functioneel Model (DSDM)
- Systeemontwerp en –bouw (DSDM) De applicatie
Het eindproduct voor de opdrachtgever zal bestaan uit een softwareapplicatie. Tijdens de Ontwerp- en Bouwiteratie (DSDM) zal de applicatie onderverdeeld worden in verschillende deelsystemen:
Beheer gebruikers en variabelen Registratie hardware Registratie software Rapportage Inlogsysteem Overige documentatie: - Installatie- en gebruikershandleiding.
8. Kwaliteit
Om de kwaliteit van de afstudeeropdracht te kunnen waarborgen is er door Avans Hogeschool aan mij een docentbegeleider toegewezen. Met de docentbegeleider zullen afspraken gemaakt worden over wat, hoe en wanneer er zaken aangeleverd moeten worden en wanneer ik hierop feedback mag verwachten. Wel is het zo dat de docentbegeleider er vanuit gaat dat al het initiatief met betrekking tot het uitvoeren van de afstudeeropdracht bij mijzelf als afstudeerder ligt.
Naast de docentbegeleider zijn tijdens de uitvoering van de afstudeeropdracht mijn leidinggevende (de opdrachtgever) en interne collega’s van AmITS beschikbaar voor input. Verder zijn op de afdeling Ontwikkeling van AmITS eventueel collega’s beschikbaar met technische ‘know-how’ op het gebied van softwareontwikkeling.
Voor de documentatie zal er steeds gebruik gemaakt worden van hetzelfde template. Ook zal de documentatie, voor dat deze opgeleverd wordt, gecontroleerd worden op juiste spelling en grammatica. De documenten zullen door meerdere personen, waaronder collega’s en de afstudeerbegeleider, gelezen worden en worden gecontroleerd op eventuele fouten.
Wanneer er een prototype gereed is (in de Ontwerp- en bouwiteratie) dan zal deze direct worden getest door collega’s van de afdeling Beheer. Hierdoor kunnen eventueel wenselijke aanpassingen direct doorgevoerd worden binnen het ontwikkeltraject.
Tenslotte zal het volgen van een softwareontwikkelmethode bijdragen aan de waarborging van de kwaliteit van het afstudeerproject. Immers geeft het gebruik van een softwareontwikkelmethode structuur aan het gehele ontwikkelproces.
9. De projectorganisatie
Er is gekozen om voor dit project geen projectorganisatie samen te stellen.
Wel zal bij de uitvoering van diverse fasen binnen dit project een beroep worden gedaan op interne medewerkers van Automotive IT Services B.V.
De reden dat er niet gekozen wordt voor een projectorganisatie is dat het project van dusdanig kleinschalige aard is dat men het binnen AmITS onnodig acht hiervoor een projectorganisatie samen te stellen.
10.
Planning
Aanvankelijk zou de afstudeeropdracht worden uitgevoerd in kwartaal 3 en 4 van mijn 4e schooljaar.
Vanaf 1 februari 2010 kan ik starten met het afstudeerproject en in eerste instantie zou het afstudeerproject 28 juni 2010 afgerond moeten zijn. Aangezien het behalen van deze datum onrealistisch lijkt gezien de hoeveelheid werk in de beschikbare tijd, is afgesproken met Avans dat ik 25 augustus het afstudeerproject ga presenteren en verdedigen. Uiterlijk 13 augustus dient alles definitief opgeleverd te worden.
Hieronder wordt middels een schema beschreven wanneer en in welk tijdsbestek bepaalde werkzaamheden zullen worden uitgevoerd. Aangezien er mogelijk bepaalde werkzaamheden niet tijdig afgerond kunnen worden, zullen er eventueel tijdens het project verschuivingen plaatsvinden in het schema. Ook is er nog geen ontwikkelmethode gekozen, waardoor de werkzaamheden nog niet ondergebracht kunnen worden in verschillende fasen en er waarschijnlijk nog werkzaamheden bijkomen en/of komen te vervallen. Vast staat in ieder geval de einddatum. Hiervan kan niet worden afgeweken.
Activiteit: Startdatum: Einddatum:
Onderzoeken technische mogelijkheden m.b.t. afstudeeropdracht
01-03-2010 31-03-2010
Schrijven Plan van Aanpak 01-04-2010 10-04-2010
Onderzoek ontwikkelmethodes en keuze ontwikkelmethode 11-04-2010 16-04-2010 Onderzoek bestaande CMDB applicaties 17-05-2010 23-05-2010
Uitvoeren onderzoek EGL 24-05-2010 30-05-2010
Activiteiten Haalbaarheidsonderzoek en Bedrijfsanalyse-iteratie: Uitvoeren en schrijven rapportage Haarbaarheids- en
bedrijfsonderzoek
17-04-2010 23-05-2010 Activiteiten Functioneel Model-iteratie:
Realiseren en schrijven rapportage Functioneel Model 24-05-2010 30-06-2010 Activiteiten Ontwerp- en Bouwiteratie:
Prototype: Basis applicatie en functionaliteiten onderdeel beheer
01-06-2010 30-06-2010
Prototype: Registratie hardware 01-07-2010 11-07-2010
Prototype: Registratie software 12-07-2010 18-07-2010
Prototype: Rapportage hardware, software en voorraad 19-07-2010 01-08-2010
Prototype: Inlogfunctionaliteit 02-08-2010 05-08-2010
Tabel 1: Planningschema uitvoering project
Nadat een prototype is ontworpen en gebouwd (Ontwerp- en bouwiteratie) wordt deze vervolgens getest door collega’s van de afdeling Beheer. Feedback kan zodoende direct verwerkt worden in de applicatie. Ook zal het Functioneel Model worden voorgelegd aan de collega’s, zodat ook al in deze fase van het project eventueel feedback gegeven kan worden voor verwerking in de applicatie.
11.
Kosten en baten
11.1 Kosten
Het afstudeerproject zal ik gaan uitvoeren bij mijn huidige werkgever. Het uitvoeren van het project kost vanzelfsprekend tijd. Deze tijd gaat gedeeltelijk ten koste van de tijd welke normaal gesproken besteed wordt aan andere werkzaamheden voor de werkgever. In die optiek kost het uitvoeren van het project AmITS dus geld. De hoeveelheid tijd die ik kan besteden aan mijn afstuderen binnen werktijd is afhankelijk van de situatie op het werk. Aangezien de dagelijkse werkzaamheden gewoon doorgaan en deze bij hoge prioriteit voorgaan op het afstuderen, is het vooraf moeilijk te bepalen hoeveel tijd er aan het uitvoeren van het afstudeerproject besteed kan worden binnen werktijd. Hierdoor is het vrijwel onmogelijk om een inschatting te maken van de loonkosten.
Naast tijd zullen er ook hulpmiddelen beschikbaar gesteld worden door de werkgever voor de uitvoering van de afstudeeropdracht. Aangezien er geen nieuwe hardware aangeschaft hoeft te worden, vinden hier naast afschrijving en stroomkosten geen kosten plaats. Voor het ontwerpen en ontwikkelen van de applicatie zal waar mogelijk gebruik worden gemaakt van bestaande en/of vrij verkrijgbare opensource producten.
Zoals eerder aangegeven is het de bedoeling dat de applicatie wordt ontwikkeld voor een WebSphere omgeving. Hierdoor hoeven er geen kosten meer gemaakt te worden in hardware en softwarelicenties voor een nieuwe webserver.
11.2 Baten
Indien het project succesvol afgerond wordt en de applicatie in gebruik genomen kan worden, dan heeft AmITS hier uiteraard baat bij. Bij de keuze van een afstudeeropdracht heb ik bewust een onderwerp gekozen waarbij ik iets kan ontwikkelen waarmee ik en mijn collega’s voordeel kunnen behalen. Wanneer het registreren van hard- en software minder omslachtig wordt, dan zal de registratie beter bijgehouden worden. Wanneer het genereren van rapportages met betrekking tot hard- en software, voorraad- en licentiebeheer en het zoeken naar documentatie minder tijd in beslag neemt, kost dit de afdeling beheer minder tijd en dus de werkgever dus ook minder geld. Ook zal een goede registratie minder irritaties opleveren bij de directeur, aangezien hij nu snel voorzien kan worden van gevraagde rapportages.
12.
Risico´s
Het succesvol slagen van het afstudeerproject is van diverse factoren afhankelijk. Er kunnen ook situaties ontstaan die een succesvolle afronding in de weg kunnen staan en zodoende een risico vormen. Hieronder staan de situaties omschreven die hier mogelijk een oorzaak van kunnen worden:
Onvoldoende tijd;
Er kunnen op het werk of privé situaties ontstaan waardoor er te weinig tijd overblijft voor het werken aan de afstudeeropdracht. Er kunnen bijvoorbeeld veelvuldig storingen ontstaan die met hoge prioriteit moeten worden opgelost.
Afhankelijkheid andere projecten;
Zoals eerder aangegeven gaat een collega binnen AmITS ITIL implementeren. Mede vanuit het oogpunt van ITIL zullen er diverse functionele wensen en eisen opgesteld gaan worden. Hierdoor ben ik dus min of meer afhankelijk van mijn collega en kan het project vastlopen als de functionele wensen en eisen niet of niet op tijd worden aangeleverd.
Wisselende functionele wensen en eisen;
Wanneer functionele wensen en eisen ineens veranderen, dan kan dit een gevaar vormen voor de voortgang van het project.
Afwezigheid;
Personen die betrokken zijn bij de uitvoering van de afstudeeropdracht of ikzelf kunnen om wat voor reden dan ook onverwacht langdurig afwezig zijn. Wanneer bijvoorbeeld de docentbegeleider lange tijd onbereikbaar is dan kan het project hierop in zijn geheel of gedeeltelijk vastlopen.
Verkeerde keuzes;
Er kunnen bij de selectie van ontwikkelmethodes, programmeertalen en platformen verkeerde keuzes gemaakt worden. Wanneer deze niet op korte termijn gecorri-geerd kunnen worden dan bestaat het risico dat het onmogelijk wordt om het project tijdig af te ronden.
13.
Bronnen
De gebruikte bronnen welke gebruikt zijn bij het opstellen van dit Plan van Aanpak zijn: Boeken:
Stapleton, Jennifer (2005),
DSDM De methode in de praktijk (2e editie)
Documenten:
Avans Hogeschool, Academie voor ICT en Business, Handboek Afstuderen Deeltijd 2009-2010 Informatica Haperen, Eric van (2010),
Voorstel afstudeeropdracht Websites:
Blackboard van Avans Hogeschool, bb.avans.nl Rüttchen, www.ruttchen.nl Van Dale, www.vandale.nl Scriptie Overzicht, www.scriptieoverzicht.nl/planvanaanpak Wikipedia: nl.wikipedia.org/wiki/Softwareontwikkelmethode
CMDB Applicatie
Onderzoek Ontwikkelmethodes
Door : Eric van Haperen Studentnummer : 2005033
Kenmerk : OO
Datum : 19 april 2010
Automotive IT Services B.V.
Rapportage Onderzoek Ontwikkelmethodes
0.2 16 april 2010 Conclusie toegevoegd
Automotive IT Services B.V.
Rapportage Onderzoek Ontwikkelmethodes
2 Watervalmethode 23 2.1 Omschrijving 23 2.2 Voordelen 24 2.3 Nadelen 24 3 V-model 25 3.1 Omschrijving 25 3.2 Voordelen 26 3.3 Nadelen 26 4 RUP 28 4.1 Inleiding 28 4.2 Uitgangspunten 28 4.3 Fasering 28 4.4 Disciplines 29 5 DSDM 30 5.1 Inleiding 30 5.2 Basisprincipes 30 5.3 Fasen 30 5.4 Timeboxing 31 5.5 MoSCoW 31 6 Conclusie 33 7 Bronnen 34
1. Inleiding
In het kader van het afstuderen voor de deeltijdopleiding Informatica, welke ik volg aan de Avans Hogeschool, heb ik een kort onderzoek uitgevoerd naar enkele bekende software-ontwikkelmethodes. Doel van dit korte onderzoek is het vinden van een geschikte ontwikkelmethode om toe te passen bij de uitvoering van de afstudeeropdracht. Een omschrijving van de uit te voeren opdracht, inclusief onder andere de probleemstelling, doelstellingen en planning, zijn omschreven in het document “Plan van Aanpak”.
Gezien het tijdsbestek van 20 weken waarin de afstudeeropdracht dient te worden uitgevoerd is het van groot belang dat er een goed toe te passen keuze wordt gemaakt uit verschillende softwareontwikkelmethodes. Immers is het vrijwel onmogelijk om tijdens een redelijk ver gevorderd stadium van het project nog van ontwikkelmethode te veranderen, omdat achteraf zou blijken dat een verkeerde keuze is gemaakt. De deadline van het project zou hierdoor waarschijnlijk niet meer kunnen worden behaald. Bovendien moet een softwareontwikkelmethode structuur geven aan het gehele traject van de afstudeeropdracht en een verkeerde structuur kan een geheel verkeerd verloop van de uitvoering van het project betekenen. Dit zijn dan ook voor mij de belangrijkste redenen om vooraf aan het project een onderzoek uit te voeren naar verschillende ontwikkelmethodes.
In hoofdstuk 2 tot en met 5 van dit document zijn er omschrijvingen te vinden van vier verschillende modellen. Hierbij zijn onder meer de belangrijkste kenmerken, procesactiviteiten en voor- en nadelen van deze verschillende ontwikkelmethodes te vinden. De volgende modellen komen aan bod:
Watervalmethode V-Model
RUP DSDM
Deze zijn allen in de loop van de opleiding Informatica behandeld. Voordat ik aan dit onderzoek begon had ik dus al kennis van bovenstaande methodes.
In hoofdstuk 6 zal vervolgens een conclusie gegeven worden waarbij ik aangeef voor welke softwareontwikkelmethode ik uiteindelijk heb gekozen en op basis van welke argumenten.
In het laatste hoofdstuk staat tenslotte een literatuurlijst met bronnen welke ik gebruikt hebt voor het onderzoek.
14. Watervalmethode
14.1 Omschrijving
De watervalmethode is een oude, maar nog altijd veel toegepaste methode voor softwareontwikkeling. Deze ontwikkelmethode kent meerdere fasen, namelijk:
Definitiestudie/analyse;
In deze fase wordt gedefinieerd wat het doel is van de te ontwikkelen software. Basisontwerp;
Er wordt een meer gedetailleerde omschrijving gemaakt van wat de te ontwikkelen applicatie moet kunnen.
Technisch ontwerp/detailontwerp;
Wanneer deze fase is bereikt dan zullen de functionaliteiten, zoals deze zijn uitgedacht in het basisontwerp, worden vertaald naar een ontwerp waarin duidelijk wordt hoe deze functionaliteiten binnen de applicatie gerealiseerd gaan worden. Bouw/implementatie;
In deze fase wordt zal de applicatie aan de hand van het technisch ontwerp gebouwd gaan worden. Hier wordt dus de daadwerkelijke broncode gechreven. Testen;
De applicatie wordt getest. Uit deze test zal blijken of alle functionaliteiten, welke zijn vastgelegd in voorgaande fasen, in de applicatie aanwezig zijn volgens het eerder uitgedachte ontwerp. Mochten er nog eventuele fouten in de applicatie aanwezig zijn dan zullen deze nu alsnog boven water komen.
Integratie;
Als het systeem in de vorige fase als zijnde “klaar” is bestempeld dan kan deze worden geïntegreerd binnen een bedrijf. De integratie zal dus gerealiseerd worden in deze fase.
Beheer en onderhoud.
Het systeem zal na de integratie onderhouden en beheerd moeten worden. De overdracht hiervan is ondergebracht in de laatste fase van dit model.
Bovenstaande fasen worden van boven regelmatig vloeiend naar beneden afgerond. Er zal dus niet worden begonnen aan een volgende fase voordat de voorgaande fase is afgerond. In een schematische weergave ziet dat er als volgt uit:
14.2 Voordelen
De belangrijkste voordelen van het gebruik van de Watervalmethode zijn:
Voordat men bij de Watervalmethode doorgaat naar een volgende fase word er eerst zorg voor gedragen dat de huidige fase goed is afgerond. Dit verkleind het risico aanzienlijk dat men tegen fouten aanloopt die veel eerder in het ontwikkelproces gemaakt zijn. Hoe later men fouten ontdekt, hoe moeilijker deze in de regel zijn op te lossen.
Er wordt in deze methode veel aandacht aan het maken van documentatie. Dit niet bij alle ontwikkelmethodes het geval. Het documenteren kost tijd, maar is van grote waarde wanneer het project bijvoorbeeld in zijn geheel of gedeeltelijk overgedragen dient te worden aan mensen die niet eerder betrokken waren bij het ontwikkelproject.
Het is een erg bekende ontwikkelmethode. Er is veel informatie over beschikbaar en er zijn veel mensen die kennis bezitten van dit model.
Het is vergeleken met veel andere softwareontwikkelmethodes vrij eenvoudig van opzet. Er zijn vastgestelde fasen die men één voor één doorloopt.
14.3 Nadelen
Uiteraard kent het gebruik van de Watervalmethode ook nadelen. Enkele belangrijke nadelen zijn: Wanneer een voorgaande fase verandert, dan moeten meerdere fasen in het geheel
opnieuw doorlopen worden. Dit kan erg lastig en tijdrovend worden wanneer bijvoorbeeld de functionele eisen wijzigen wanneer men al bezig is met de bouw van de applicatie. Men kan pas doorgaan met de volgende fase als de voorgaande fase is afgerond. Zo
kunnen bijvoorbeeld mensen pas beginnen met het bouwen van de applicatie wanneer de ontwerpers klaar zijn met het ontwerp van de applicatie. Hierdoor kan er minder efficiënt met betrekking tot tijd gewerkt worden.
Er wordt pas laat in het ontwikkelproces getest. Fouten kunnen het best zo vroeg mogelijk in het traject gevonden en hersteld worden, dit is altijd goedkoper en eenvoudiger. Bij sommige andere ontwikkelmethodes worden applicaties of deelproducten hiervan op verschillende momenten getest.
Zoals eerder vermeld wordt er veel aandacht besteed bij de Watervalmethode aan het maken van documentatie. Dit is enerzijds voordelig, maar anderzijds kan dit ook nadelig zijn. Het moeten maken van te veel documentatie kan in bepaalde situaties erg inefficiënt zijn, bijvoorbeeld wanneer men werkt aan een klein project met een beperkt aantal mensen.
15. V-model
15.1 Omschrijving
Het V-model is een ontwikkelmethode waarin naast aan ontwikkeling ook veel aandacht wordt besteed aan verificatie. Het model is onderverdeeld in verschillende fasen, waaraan aan het eind bepaalde producten worden opgeleverd. Er kan, net zoals bij de Watervalmethode, pas doorgegaan worden met de volgende fase nadat de huidige fase is afgerond. De fasering van het V-model ziet er als volgt uit:
Figuur 3: Fasering van het V-model
De fasen van het ontwikkelingproces staan in bovenstaand diagram aan de linkerkant. Aan de rechterkant staan de testfasen. Iedere ontwikkelfase is gekoppeld aan een testfase. Men is bij het V-model vrij in de keuze voor de te gebruiken technieken binnen de verschillende fasen.
Het ontwikkelproces (linker kant) ziet er over het algemeen als volgt uit: Business Case;
Het maken van de Business Case is de eerste stap. Hierin wordt beschreven wat er door de klant wordt verwacht van het nieuwe systeem.
Eisen;
Bij eisen wordt door de klant beschreven wat de vereisten zijn van het systeem om te worden geaccepteerd. Dit is een beschrijving van zowel de functionele als niet-functionele vereisten.
Systeemspecificatie;
Vereisten worden vervolgens doorgespeeld naar de ontwikkelaars. Deze maken dan een systeemspecificatie. Hierin verandert de focus van wat het systeem moet kunnen naar de manier waarop men dit wil bereiken, dus welke methode, software, hardware is nodig om aan de vereisten te kunnen voldoen.
Systeemontwerp;
Andere ontwikkelaars gaan vervolgens werken aan het systeemontwerp. Deze wordt opgesteld aan de hand van de reeds gemaakte systeemspecificatie. De verschillende componenten worden aan elkaar gekoppeld en de relaties tussen de componenten worden beschreven.
Componentontwerp;
Ieder component heeft ook een eigen design, waar in detail wordt beschreven hoe het zijn processen zal verwerken.
Realisatie.
De componenten worden gebouwd, het systeem is dan klaar voor het testproces. Het testproces dat hoort bij de hierboven beschreven methode ziet er als volgt uit, dit is dus de rechterkant van het model:
Component-test;
Hier worden de individuele componenten getest. Deze moeten voldoen aan de voorwaarden zoals deze beschreven zijn in het componentontwerp.
Interface-test;
Wanneer componenten afzonderlijk zijn getest begint de interface-test. Hierbij wordt getest of de componenten nog naar wens functioneren wanneer deze aan elkaar worden gekoppeld.
Systeemtest;
Bij de systeemtest wordt gekeken of alle vereisten kunnen worden gehaald. Dit is niet het testen van verschillende componenten, maar meer de niet-functionele eisen zoals betrouwbaarheid, performance, etc.
Acceptatietest;
De acceptatietest test feitelijk de business case: levert het systeem wat de klant er van verwacht om voor hem een voordeel op te leveren in zijn werkveld? Met andere woorden zijn alle vereisten bereikt.
Release test.
De release test is het testen hoe het systeem uiteindelijk draait in de organisatie.
15.2 Voordelen
De belangrijkste voordelen van het gebruik van het V-model zijn:
Voordat men bij het V-model doorgaat naar een volgende fase word er eerst zorg voor gedragen dat de huidige fase goed is afgerond. Dit verkleind het risico aanzienlijk dat men tegen fouten aanloopt die veel eerder in het ontwikkelproces gemaakt zijn. Hoe later men fouten ontdekt, hoe moeilijker deze in de regel zijn op te lossen;
Het is een erg bekende ontwikkelmethode. Er is veel informatie over beschikbaar en er zijn veel mensen die kennis bezitten van dit model;
Elke fase van integratie wordt getest.
15.3 Nadelen
De belangrijkste nadelen van het gebruik van het V-model zijn: Het V-model gaat er vanuit dat vereisten niet veranderen; Het ontwerp wordt niet geverifieerd;
Vereisten worden niet geverifieerd;
Er wordt pas laat in het ontwikkelproces getest. Fouten kunnen het best zo vroeg mogelijk in het traject gevonden en hersteld worden, dit is altijd goedkoper en eenvoudiger. Bij sommige andere ontwikkelmethodes worden applicaties of deelproducten hiervan op verschillende momenten getest.
16. RUP
16.1 Inleiding
RUP staat voor Rational Unified Process. Het is een populaire, op iteraties gebaseerde softwareontwikkelmethode. De term iteratie betekend herhaling, wat in softwareontwikkeling staat voor het herhaald doorlopen van een ontwikkelproces. Hierin wordt in een afgebakende, korte periode een samenhangende hoeveelheid functionaliteit ontworpen, gerealiseerd of geaccepteerd. In tegenstelling tot de Watervalmethode, waarbij eerst alles volledig gespecificeerd moet worden, kan er in een iteratieve aanpak al besloten worden om te bouwen en daarna te evalueren op basis van het resultaat.
16.2 Uitgangspunten
RUP is gebaseerd op de volgende kernstatements: Pas je proces aan;
Maak het RUP-proces op maat voor de organisatie en het project. Geef belanghebbenden een stem;
Betrek belanghebbenden van het product om tot een een uitgebalenceerd pakket van eisen te komen.
Bestrijd risico’s vroeg en continu;
Hoe eerder een risico gezien en bestreden wordt, hoe minder kosten het met zich meebrengt.
Lever iteratief iets van waarde voor de klant;
Dit vergroot het vertrouwen bij de klant en bovendien is het een betrouwbare basis voor het meten van de voortgang.
Speel in op wijzigingen;
Door de scope van het systeem zo laat mogelijk en iteratief te detailleren wordt de impact van wijzigingen geminimaliseerd.
Stabiliseer de architectuur in werkende code;
Controleer of de gekozen softwarearchitectuur de belasting van het systeem aankan, zodat in een zo vroeg mogelijk stadium actie kan worden ondernomen wanneer het niet naar behoren werkt.
Werk samen als één team;
Voor het succesvol ontwikkelen van software is goede samenwerking en communicatie van noodzakelijk belang.
Kwaliteit is een manier van leven, geen toevoeging achteraf.
Iedereen dient een optimale bijdrage te leveren aan het product en proces.
16.3 Fasering
Een project wordt bij de toepassing van RUP verdeeld over vier verschillende fasen: Inceptiefase (Aanvang);
In deze fase worden de haalbaarheid van het project, de inhoud en de project-grenzen bepaald. Ook worden onder meer de globale kostprijs en de verwachte baten van het project geschat en de belangrijkste risico's ingeschat. Het uiteindelijke doel van deze fase is een haalbaarheidsstudie voor het project.
Elaboratiefase (Detaillering);
In de Elaboratiefase worden onder andere de functionele eisen bepaald en wordt de systeemarchitectuur ontworpen. Het uiteindelijke doel van deze fase is de totstandkoming van een projectplan.
Constructiefase (Bouw);
Aan de hand van de systeemarchitectuur wordt het product ontwikkeld. Transitiefase (Overgang);
Het systeem wordt in deze laatste fase getest door de belanghebbenden. Daarnaast worden er voorbereidingen getroffen voor het in productie nemen, de nazorg en overdracht van de verantwoordelijkheden.
16.4 Disciplines
RUP-disciplines zijn groeperingen van taken binnen het ontwikkelteam waarvoor vergelijkbare kennis en vaardigheden benodigd zijn. We onderscheiden de volgende disciplines:
Requirements; Architectuur en Bouw; Test;
Ondersteunding; Projectmanagement.
Hieronder wordt weergegeven in welke mate de verschillende disciplines binnen RUP betrokken zijn bij de verschillende fasen:
17. DSDM
17.1 Inleiding
DSDM is een softwareontwikkelmethode waarbij gebruik wordt gemaakt van intensieve gebruikersparticipatie, evolutionaire prototyping, timeboxing en prioritering. Het kan toegepast worden bij de ontwikkeling van zowel grote als kleine systemen.
DSDM heeft een iteratieve, incrementele opleverstrategie. Dit houdt in dat het systeem als verschillende deelproducten, ofwel incrementen, zal worden opgeleverd. Deze deelproducten worden bij DSDM ook wel mijlpalen genoemd.
17.2 Basisprincipes
DSDM is gebaseerd op de volgende basisprincipes:
1. Gebruikers moeten actief deelnemen aan het proces;
2. Teams moeten bevoegd zijn om beslissingen te nemen op het gebied van systeemontwikkeling;
3. Vaak en regelmatig opleveren van deelproducten is een prioriteit;
4. De businessoplossing is het doel, doormiddel van iteratieve en incrementele ontwikkeling dient men tot de oplossing te komen;
5. Producten kunnen pas worden geaccepteerd als deze geschikt bevonden worden voor bedrijfsdoeleinden;
6. Alle veranderingen welke worden gemaakt tijdens ontwikkeling zijn terug te draaien; 7. Eisen zijn erg algemeen en op hoog niveau vastgelegd;
8. Testen gebeurd gedurende het gehele ontwikkeltraject;
9. Samenwerking tussen belanghebbenden is van essentieel belang.
17.3 Fasen
Een ontwikkeltraject met DSDM bestaat uit de volgende fasen: Haalbaarheidsonderzoek;
Hierin wordt bepaald of het systeem, met de gekozen technische realisatie, kosten en duur, geschikt is voor het bedrijf.
Bedrijfsanalyse;
In deze fase worden de primaire functies van het systeem bepaald alsmede de gewenste betrouwbaarheid en prestaties;
Functioneel Model Iteratie;
Hierin wordt gebruikt gemaakt van prototyping om gebruikerseisen te bepalen, informatie te verzamalen, de functionaliteit te tonen niet-functionele eisen te achterhalen. Deze fase wordt net zo vaak herhaald als men nodig acht.
Ontwerp en Bouw Iteratie;
Nog tijdens het bepalen wát er gerealiseerd moet gaan worden, in de vorige fase, kan er begonnen worden met de verdere uitwerking hiervan in deze ontwerp- en bouwfase. Deze fase heeft als doel het opleveren van een design prototype dat voldoet aan de gestelde functionele en niet-functionele eisen. Deze fase wordt vaker uitgevoerd.
Implementatie.
In deze fase zal het systeem worden opgeleverd naar de eindgebruikers voor evaluatie. Het systeem kan vervolgens definitief worden opgeleverd, of teruggaan naar een eerdere fase.
Figuur 5: DSDM-procesdiagram
17.4 Timeboxing
Timeboxing is de techniek die zorgt voor de tijdige oplevering en realisatie van het project. Binnen DSDM projecten is de opleverdatum vastgesteld en de productiecapaciteit is daardoor duidelijk te benoemen (op basis van beschikbare tijd en resources).
Timeboxing zorgt ervoor dat tijd en geld worden vastgesteld, en dat de functionaliteit wordt gevarieerd. Het managen van functionaliteit gebeurt door middel van prioriteitstelling (MoSCoW).
17.5 MoSCoW
MoSCoW is een acroniem voor de manier waarop prioriteiten aan de vereisten worden toegekend. De “o’s” hebben hierin geen betekenis. De overige letters van het woord staan voor:
Must have;
Dit zijn vereisten die fundamenteel zijn voor het systeem. Zonder deze vereisten zou het systeem onwerkbaar en nutteloos zijn.
Dit zijn vereisten die bij een ontwikkelingstraject waarbij meer tijd beschikbaar zou zijn waarschijnlijk wel als zijnde verplicht aangemerkt zouden zijn. Het systeem zal echter zonder deze vereisten ook nuttig en bruikbaar zijn.
Could have;
Deze vereisten kunnen zonder problemen te veroorzaken uit het te ontwikkelen systeem weggelaten worden.
Want to have but will not have this time round.
Deze vereisten zijn waardevol, maar zullen waarschijnlijk niet gerealiseerd worden binnen het huidige traject. Mogelijk kunnen deze in het systeem worden opgenomen in een verdere ontwikkeling ervan.
18. Conclusie
Bij de Watervalmethode is het, evenals bij het V-model, in principe niet toegestaan om tijdens de uitvoering van het project terug te keren naar een eerder afgeronde fase. Dit betekent dat eventuele fouten welke worden ontdekt en die zijn gemaakt in een eerder afgeronde fase, pas in de eindfase van het project kunnen worden verholpen. Hetzelfde geldt bovendien voor eventuele plotseling wijzigende functionele eisen. Wanneer men al begonnen is aan het ontwerp of bouw van het systeem, dan kunnen deze gewijzigde functionele eisen pas aan het eind van het project worden opgenomen in het eindproduct. Mits hier uiteraard voldoende tijd voor over is, aangezien deze manier van softwareontwikkeling in dit soort situaties veel extra werk met zich meebrengt.
Mijn voorkeur heeft dus het gebruik van een iteratieve ontwikkelmethode. Mochten de functionele wensen in een later stadium wijzigen, wat erg aannemelijk is aangezien het afstudeerproject gerelateerd is aan een parallel lopende ITIL-implementatie, dan kom ik niet in de problemen met de deadline van het afstudeerproject. Ook heeft mijn voorkeur een incrementele oplevering van het eindproduct. Er kunnen door het testen van prototypen nieuwe wensen en eisen ontstaan die zodoende nog tijdens het ontwikkelproces kunnen worden meegenomen. Zowel RUP als DSDM zijn iteratieve, incrementele ontwikkelmethodes. Van de onderzochte softwareontwikkelmethodes blijven deze dus over.
Eén van de belangrijkste kenmerken van RUP is dat het onderscheid maakt tussen disciplines onder leden van het ontwikkelteam. Aangezien ik binnen mijn afstudeerproject als enige de rol van ontwikkelaar vervul, zie ik hier weinig voordelen in en zou dit mijn inziens het project zelfs onnodig complex maken.
Bij DSDM gaat men er van uit gaat dat gebruikers actief betrokken worden bij de ontwikkeling. Ook dit kan als nadeel worden gezien aangezien ik hierdoor erg afhankelijk word van de eindgebruikers (collega’s afdeling Beheer). Wanneer zij geen tijd of motivatie hebben om actief mee te werken aan het project, dan bestaat het risico dat deze niet succesvol kan worden afgerond. Hier ga ik echter niet van uit.
Voordeel van het gebruik van RUP boven DSDM kan zijn dat deze ontwikkelmethode over het algemeen dieper gespecificeerd is dan DSDM. Bij het gebruik van DSDM zal er op veel zaken een eigen invulling gegeven moeten worden. Bovendien zijn er bij RUP veel kant-en-klare templates voorhanden. Echter zie ik, voornamelijk omdat het eindproject een vast tijdsbestek heeft en de functionele wensen en eisen aan verandering onderhevig zijn, grotere voordelen in het gebruik van DSDM. De planning is goed onder controle te houden door het gebruik van timeboxing en de priorisering van eisen middels MoSCoW. Dit zal dan ook de ontwikkelmethode zijn welke ik zal hanteren tijdens mijn afstudeerproject.
Naast DSDM bestaat ook de variant eDSDM. Aangezien deze erg gericht is op e-commerce, wat dus niet van toepassing is op het eindproduct van de afstudeeropdracht, heb ik deze ontwikkelmethode in dit onderzoek buiten beschouwing gelaten.
19. Bronnen
De gebruikte bronnen welke gebruikt zijn bij het opstellen van dit Onderzoek Ontwikkelmethodes: Boeken:
Dekker, Eef & Collaris, Remi-Armand (2008), Rup op Maat
Stapleton, Jennifer (2005),
DSDM De methode in de praktijk (2e editie)
Documenten:
Avans Hogeschool, Academie voor ICT en Business, Handboek Afstuderen Deeltijd 2009-2010 Informatica Haperen, Eric van (2010),
Plan van Aanpak Websites:
Blackboard van Avans Hogeschool, bb.avans.nl Van Dale, www.vandale.nl DSDM Consortium, www.dsdm.org Rup op maat, www.rupopmaat.nl Wikipedia: nl.wikipedia.org/wiki/Softwareontwikkelmethode nl.wikipedia.org/wiki/Watervalmethode nl.wikipedia.org/wiki/V-model nl.wikipedia.org/wiki/Rational_Unified_Process nl.wikipedia.org/wiki/Dynamic_Systems_Development_Method
CMDB Applicatie
Haalbaarheids- en bedrijfsonderzoek
Door : Eric van Haperen Studentnummer : 2005033
Kenmerk : HBO
Datum : 11 augustus 2010
Automotive IT Services B.V.
Haalbaarheids- en bedrijfsonderzoek
1.0 16 mei 2010 Diverse aanvullingen en wijzigingen
Automotive IT Services B.V. Haalbaarheids- en bedrijfsonderzoek 2. Opdrachtomschrijving 39 2.1 Het bedrijf 39 2.2 Opdrachtomschrijving 39 2.3 Scope 39 2.3.1 Binnen de scope 39 2.3.2 Buiten de scope 40 3. Toepasbaarheidsonderzoek 41 3.1 Lijst toepasbaarheid 41 3.2 Conclusie 42
4. Onderzoek bestaande CMDB-applicaties 43
4.1 Resultaten 43 4.1.1 OneCMDB 43 4.1.2 ProcessWorx CMDB 43 4.1.3 Topdesk (middelenbeheer-module) 44 4.2 Conclusie 44 5. Bedrijfsprocessen 45
5.1 Registratie nieuwe hardware 45
5.2 Wijziging bestaande hardware 46
5.3 Registratie overige Configuration Items 46
5.4 Voorraad beheren 47
5.5 Aanmaak overzichten 47
6. Planning 49
1. Inleiding
Om te kunnen afstuderen voor de deeltijdopleiding Informatica, welke ik volg bij Avans Hogeschool, moet ik bij mijn werkgever een afstudeeropdracht uitvoeren in de vorm van een project. Dit project zal uitgevoerd worden aan de hand van de softwareontwikkelmethode DSDM. De keuze voor DSDM is genomen aan de hand van de uitvoering van een kort onderzoek naar enkele bekende softwareontwikkelmethodes4.
Figuur 6: DSDM-procesdiagram
De eerste twee fasen van DSDM bestaan uit het uitvoeren van een haalbaarheidsonderzoek en bedrijfsanalyse. De uitvoering van beide fasen staan beschreven in dit document.
In hoofdstuk 2 is de opdrachtomschrijving te vinden. Hierin staat een korte omschrijving van het bedrijf, een omschrijving van de opdracht zelf en de activiteiten welke wel en niet binnen de scope van het project vallen. In hoofdstuk 3 staat een kort onderzoek beschreven naar de toepasbaarheid van DSDM op het project. Het resultaat hiervan zal bevestigen dat DSDM wel of juist geen goede keuze is om toe te passen op het project. Er is een kort onderzoek uitgevoerd naar bestaande CMDB applicatie. De resultaten hiervan staan in hoofdstuk4. In hoofdstuk 5 staan de bedrijfsprocessen beschreven welke geraakt worden bij het implementeren van het te ontwikkelen systeem. Tenslotte staat in hoofdstuk 6 de bronvermelding van dit document. Enkele onderdelen in dit document zijn reeds eerder aan bod gekomen in andere documenten behorende bij de afstudeeropdracht5.
4 Zie hiervoor het document “Onderzoek Ontwikkelmethodes” 5 Zie ook het document “Plan van Aanpak”
20. Opdrachtomschrijving
20.1 Het bedrijf
Rüttchen is een van de grotere officiële Mercedes-Benz, Smart en Chrysler dealers van Nederland. Binnen de automotive branche is Rüttchen actief in de divisies personenwagens, bestelwagens en vrachtwagens. Rüttchen is officieel dealer voor de merken Mercedes-Benz, Smart, Chrysler, Jeep Dodge, Honda en Mitsubishi. Inmiddels heeft de organisatie 10 vestigingen. In totaal heeft men +/-450 medewerkers in dienst. De ambitie van Rüttchen is om op korte termijn tot één van de meest toonaangevende dealerbedrijven behoren, vanuit het perspectief van bestaande (en nieuwe) klanten, leveranciers, medewerkers en aandeelhouders.
Naast verkoop en onderhoud aan auto’s is Rüttchen zich ook bezig gaan houden met het concept “full service”. Hiermee willen zij bereiken dat klanten alles wat met auto’s te maken heeft bij Rüttchen kunnen krijgen, hieronder valt bijvoorbeeld Truck- & carcleaning, schadeherstel, carrosseriebouw, verzekeringen, financiering en leasing en verlengde garantie.
De IT-afdeling van Rüttchen handelt onder de bedrijfsnaam Automotive IT Services B.V. als een onderdeel van de Rüttchen Holding B.V.. Automotive IT Services B.V., afgekort AmITS, bestaat uit een directeur, een afdeling Beheer en een afdeling Ontwikkeling. De afdeling Ontwikkeling houdt zich bezig met de ontwikkeling van het eigen Dealer Management Systeem (ERP-pakket) genaamd ADIS (AutoDealer InformatieSysteem). Het pakket wordt ook gebruikt door enkele collega-dealers. De afdeling beheer verzorgt het beheer van het pakket voor Rüttchen en de andere dealerbedrijven op basis van SLA’s. Ook implementeren zij wijzigingen van ADIS in de productieomgeving. Daarnaast is de afdeling Beheer verantwoordelijk voor de gehele IT-infrastructuur van de Rüttchen-bedrijven.
20.2 Opdrachtomschrijving
De afstudeeropdracht bestaat uit het ontwerpen en ontwikkelen van een softwareapplicatie waarmee registratie van hard- en software op een eenvoudige en bovendien snelle wijze uitgevoerd kan worden. Ook dienen op eenvoudige wijze verschillende rapporten uitgedraaid en geëxporteerd te kunnen. Daarnaast moet er bijgehouden kunnen worden welke hardware er op voorraad is. Ook van de hardware op voorraad moet een rapportage gemaakt kunnen worden.
20.3 Scope
20.3.1 Binnen de scope
De volgende activiteiten vallen binnen de scope van het project:
Het uitvoeren van een kort onderzoek naar bestaande CMDB applicaties
Het uitvoeren van een kort onderzoek naar toepasbaarheid van EGL6 binnen het project
Het ontwerpen en opzetten van een MySQL database
Het installeren van een Websphere Community Edition omgeving
Het analyseren van de huidige bedrijfsprocessen welke betrekking hebben op het project Het ontwerpen van de applicatie
Het bouwen van de applicatie
Het schrijven van rapportages behorende bij DSDM:
o Haalbaarheids- en bedrijfsonderzoek o Functioneel model
o Systeemontwerp en –bouw Het realiseren van een helpfunctie
Het schrijven van installatie- en gebruikersdocumentatie
Daarnaast dienen de volgende activiteiten uitgevoerd te worden in opdracht van Avans Hogeschool:
Het schrijven van een projectvoorstel Het schrijven van een plan van aanpak Het schrijven van een procesverslag
Het presenteren en verdediging van de afstudeeropdracht
20.3.2 Buiten de scope
De volgende activiteiten vallen buiten de scope van het project: Het implementeren van de applicatie
21. Toepasbaarheidsonderzoek
21.1 Lijst toepasbaarheid
Middels het beantwoorden van de vragen (risicofactoren) in onderstaande tabel kan men nagaan of DSDM een geschikte methode is voor het project. Er worden vragen beantwoord op het gebied van de applicatie, te gebruiken technieken en het bedrijf. Hoe meer vragen met “Ja” beantwoord kunnen worden, hoe geschikter DSDM is voor toepassing binnen het project.
Nr. Risicofactor Geschik
t (J/N)
Opmerkingen
1 Is het bedrijf bekend met DSDM en accepteert men het gebruik hiervan?
J Normaal gesproken wordt binnen AmITS geen gebruik gemaakt van DSDM. Het toepassen ervan op dit project is geen bezwaar.
2 Is de ontwikkelaar bevoegd om
beslissingen te nemen m.b.t. het project?
J Beslissingen welke geen grote technische gevolgen hebben en geen kosten met zich meebrengen mogen door mijzelf genomen worden.
3 Zijn er eindgebruikers betrokken bij de ontwikkeling van de applicatie?
J Ja, er zullen medewerkers van de afdeling Beheer betrokken zijn bij de ontwikkeling van de applicatie. 4 Heeft het bedrijf de capaciteit om
regelmatig incrementen aan te leveren?
J Aangezien het om een relatief klein project gaat moet het mogelijk zijn om regelmatig incrementen aan te leveren.
5 Is het mogelijk voor de ontwikkelaar om tijdens het project de eindgebruikers te benaderen?
J De eindgebruikers zijn de collega’s van de eigen afdeling wat dus geen problemen op zal leveren.
6 Blijft het ontwikkelteam tijdens het project bestaan uit dezelfde leden?
J Het ontwikkelteam zal blijven bestaan uit dezelfde persoon. 7 Heeft de ontwikkelaar voldoende kennis
en ervaring?
J Er zal binnen het project gebruik gemaakt worden van technieken waarvan kennis reeds aanwezig is bij de ontwikkelaar of waarover deze eventueel snel te vergaren is. 8 Bestaat het ontwikkelteam uit zes of
minder personen?
J Het ontwikkelteam bestaat uit slechts één persoon.
9 Bestaat er een commerciële verhouding? J De applicatie zal worden gebruikt ter ondersteuning binnen een commercieel bedrijf.
10 Wordt er gebruik gemaakt van technieken welke geschikt zijn voor prototyping?
J Er zullen technieken gebruikt worden die geschikt zijn voor prototyping.
11 Wordt er gebruik gemaakt van een gebruikersinterface welke te demonstreren is?
J Er zal gebruik worden gemaakt van GUI’s en rapportages.
systeem?
13 De ontwikkeling is vanuit technisch oogpunt niet te complex?
J Met de huidige kennis en ervaring van de ontwikkelaar moet het project technisch gezien niet te complex zijn.
14 Kan het systeem, indien nodig, incrementeel ontwikkeld worden.
J Het is mogelijk om het systeem incrementeel te ontwikkelen. 15 Is de ontwikkeling gebonden aan een
vaste tijdsplanning.
J Het systeem moet in de afstudeerperiode gerealiseerd worden.
16 Kunnen de eisen geperiodiseerd worden? J De eisen zijn onder te verdelen op basis van prioriteiten.
17 Worden de eisen gedetailleerd vastgelegd.
J De eisen worden zo gedetailleerd mogelijk en S.M.A.R.T.7 genoteerd.
Tabel 2: Lijst toepasbaarheid DSDM
21.2 Conclusie
Uit het voorgaand onderzoek naar ontwikkelmethodes8 was reeds gebleken dat de belangrijkste
kenmerken van DSDM goed aansluiten op het project. Dit gaf echter slechts een globaal beeld van de toepasbaarheid van DSDM op het project. Door het invullen van de lijst in de vorige paragraaf krijgt men een nog beter antwoord op de vraag of DSDM geschikt is om toe te passen in deze situatie. Alle vragen in de lijst in de voorgaande paragraaf kunnen beantwoord worden met een ‘Ja’, wat hierdoor nogmaals bevestigd dat DSDM een zeer geschikte softwareontwikkelmethode is om toe te passen op de ontwikkeling vanhet systeem.
7 S.M.A.R.T. = Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden 8 Zie document “Onderzoek Ontwikkelmethodes”
22.
Onderzoek bestaande CMDB-applicaties
Zoals te lezen is in de opdrachtomschrijving in dit document is het doel van het project het ontwikkelen van een softwareapplicatie waarmee registratie van hard- en software op een eenvoudige en bovendien snelle wijze uitgevoerd kan worden. Naast het zelf ontwikkelen van dergelijke applicatie is het wellicht mogelijk om een bestaande applicatie te implementeren welke aan de wensen en eisen van AmITS voldoet. Na een pakketselectie is besloten om de volgende applicaties onder de loep te nemen:
OneCMDB
ProcessWorx CMDB
Topdesk (middelenbeheer-module)
De ondervonden voor- en nadelen per pakket staan in het volgende hoofdstuk omschreven. In het laatste hoofdstuk staat de conclusie van dit korte onderzoek.
22.1 Resultaten 22.1.1 OneCMDB
Voordelen: Webbased Multi-user
Schematische weergave relaties binnen de CMDB Exportfunctie rapporten naar bestanden
Ondersteuning van zowel hard- als software Mogelijk om CI’s onderling te koppelen
Rapporten zijn zelf toe te voegen en volledig naar wens aan te passen Duidelijke GUI
Gratis verkrijgbaar
Opensource, dus functionele aanpassingen maken in applicatie is mogelijk Nadelen:
Geen voorraadbeheer
Geen grafische tool voor ontwerpen rapporten Pakket is vrij traag
22.1.2 ProcessWorx CMDB
Voordelen:
Gebruiksvriendelijke GUI
Ondersteuning voor zowel hardware, software als documentatie Relaties tussen CI’s zijn vrijwel onbeperkt te maken
Vrije velden zijn (beperkt in aantal) toe te voegen aan CI’s Voorgedefinieerde filters zijn toe te passen op rapporten Exportfunctie CI’s naar bestand
Nadelen:
Closed-source, functionele aanpasingen maken in de applicatie is dus onmogelijk Het pakket kost geld
Het pakket moet op werkstations geïnstalleerd worden
Rapporten zijn (naast toepassing filtering) niet aan te passen en/of toe te voegen Geen voorraadbeheer
22.1.3 Topdesk (middelenbeheer-module)
Voordelen:
Gebruiksvriendelijke GUI
Ondersteuning voor zowel hardware, software als documentatie Configuraties zijn samen te stellen uit hardware-items
Mogelijkheid om budgethouders toe te kennen aan CI’s Voorgedefinieerde filters zijn toe te passen op rapporten Nadelen:
Closed-source, functionele aanpasingen maken in de applicatie is dus onmogelijk Het pakket kost geld
CMDB-module is niet los verkrijgbaar
Rapporten zijn niet aan te passen en/of toe te voegen Geen voorraadbeheer
22.2 Conclusie
Iedere applicatie heeft zijn eigen voor- en nadelen. Geen van de applicaties kan voorzien in alle gestelde functionele eisen. Het is van belang dat er gewerkt kan worden bij AmITS met een applicatie waarin alle gewenste functies beschikbaar zijn. Open-source pakketten zijn eventueel aan te passen, maar het aanpassen van de bestaande pakketten kost waarschijnlijk meer tijd dan het van begin af aan zelf ontwikkelen van een pakket. Bovendien kan in een eigen ontwikkeld pakket overbodige functionaliteiten weggelaten worden wat de onderhoudbaarheid van het pakket ten goede komt. De ontwikkeling van een eigen applicatie behoudt daarom dan ook de voorkeur.
23. Bedrijfsprocessen
De bedrijfsprocessen binnen AmITS, welke bertekkening hebben op het te ontwikkelen systeem, worden in dit hoofdstuk omschreven. Ook zullen de processen worden verduidelijkt middels diagrammen.
De processen welke aan bod komen in dit hoofdstuk zijn: Registratie nieuwe hardware
Wijziging bestaande hardware
Registratie overige Configuration Items9
Wijzigen voorraad Overzichten creeëren
23.1 Registratie nieuwe hardware
Bij AmITS is het van groot belang dat nieuwe hardware wordt geregistreerd voordat deze word uitgegeven aan de eindgebruikers. Momenteel wordt de registratie bijgehouden in de spreadsheetbestand. Het proces ziet er bij het registreren van nieuwe hardware in dit bestand als volgt uit:
Installatie hardware
Bepalen nieuw intventarisnummer
Registreren
gegevens Configuration ItemNieuw
Hardware geregistreerd
Figuur 7: Procesdiagram registratie nieuwe hardware
De eerste stap in de procedure van de registratie van hardware is het bepalen van het inventarisnummer. Dit is een uniek kenmerk dat bestaat uit een categoriecode en een volgnummer. Wanneer deze bekend is wordt deze inclusief alle overige gewenste gegevens ingevoerd in het bestand.
9 Configuration Item = Een component dat deel uitmaakt van, of direct gerelateerd is aan, de IT infrastructuur.
23.2 Wijziging bestaande hardware
Wanneer er een wijziging optreed met betrekking tot reeds bestaande hardware dan dient altijd gecontroleerd te worden of de huidige registratie van het Configuration Item nog actueel is. Soms komt het voor dat reeds bestaande hardware nog niet is opgenomen in de registratie. In dit geval dient deze hierin alsnog opgenomen te worden.
Dit proces ziet er als volgt uit:
Wijziging bestaande hardware Is het CI bekend binnen de registratie? Bepalen nieuw intventarisnummer Registreren gegevens Nieuw Configuration Item Zijn huidige gegevens actueel? Gegevens bijwerken Registratie bijgewerkt Registratie bijgewerkt Bijgewerkt Configation Item Registratie reeds actueel Nee Ja Nee Ja
Figuur 8: Procesdiagram wijziging registratie bestaande hardware
23.3 Registratie overige Configuration Items
Overige Configuration Items naast hardware worden in de huidige situatie niet in een registratie bijgehouden. Hiervan bestaan dus vanzelfsprekend momenteel ook geen bedrijfsprocessen. De volgende processen worden gecreëerd met de implementatie van de applicatie:
Registratie software (en beschikbare licenties)
Registratie documentatie (waaronder installatieprocedures en SLA’s) Registratie voorraad en uitgifte hardware
Nieuw Configuration Item
Bepalen nieuw intventarisnummer
Registreren
gegevens Configuration ItemNieuw
Configuration Item geregistreerd
Figuur 9: Procesdiagram registratie Configuration Item
23.4 Voorraad beheren
Wanneer er hardware wordt uitgegeven of wanneer er nieuwe hardware voor voorraad wordt aangeschaft, dan zal de voorraadregistratie moeten worden bijgewerkt. Momenteel wordt er niet voor alle hardware een voorraadregistratie bijgehouden. Waarbij dit wel gebeurd wordt dit bijgehouden in losse spreadsheetbestanden.
In de nieuwe situatie ziet dit proces er als volgt uit: Nieuwe voorraad /
uitgifte uit voorraad
Wijziging vooraad in registratie
Voorraad bijgewerkt
Figuur 10: Procesdiagram wijziging voorraad in registratie
23.5 Aanmaak overzichten
Wanneer er door de directie wordt gevraagd om bepaalde overzichten van huidig operationeel zijnde hardware, dan worden deze aangemaakt door selecties te maken (filteringen) binnen het registratiebestand. Dit kunnen bijvoorbeeld overzichten zijn per vestiging (hoeveel pc’s zijn er aanwezig binnen een bepaalde vestiging), per type hardware (hoeveel pc’s komen in aanmerking voor vervanging), etc.
Dit proces ziet er als volgt uit: Verzoek aanlevering overzicht CI's Selectie maken in hardwareregistratie Overzicht aangemaakt Overzicht Configuration Items
24. Planning
Voor het project was tijdens het opstellen van dit onderzoek reeds een eerste versie van de planning10 gemaakt. Deze is onderverdeeld in verschillende iteraties. De applicatie is binnen de
Ontwerp- en Bouwiteratie onderverdeeld in verschillende prototypen. De volgende activiteiten zijn toegevoegd:
Haalbaarheidsonderzoek en Bedrijfsanalyse iteratie:
o Uitvoeren en schrijven rapportage Haarbaarheids- en bedrijfsonderzoek activiteiten Functionele model-iteratie:
o Realiseren en schrijven rapportage Functioneel Model activiteiten Ontwerp- en Bouwiteratie:
o Prototype: Beheer gebruikers en variabelen o Prototype: Registratie hardware
o Prototype: Registratie software o Prototype: Rapportage
o Prototype: Inlogsysteem
25. Bronnen
De gebruikte bronnen welke gebruikt zijn bij het opstellen van dit Haalbaarheids- en bedrijfsonderzoek:
Boeken:
Stapleton, Jennifer (2005),
DSDM De methode in de praktijk (2e editie)
Documenten:
Haperen, Eric van (2010), Plan van Aanpak
Haperen, Eric van (2010), Onderzoek Ontwikkelmethodes Websites:
Blackboard van Avans Hogeschool, bb.avans.nl
Van Dale, www.vandale.nl DSDM Consortium,
CMDB Applicatie
Functioneel Model
Door : Eric van Haperen Studentnummer : 2005033
Kenmerk : FM
Datum : 11 augustus 2010
Automotive IT Services B.V. Functioneel Model
1.0 1 juli 2010 Aanvulling ontbrekende hoofdstukken
Automotive IT Services B.V. Functioneel Model 2. Systeemeisen 55 2.1 Functionele eisen 55 2.2 Niet-functionele eisen 56 3. Use cases 58 3.1 Inloggen 58 3.2 Toevoegen hardware 58 3.3 Weergeven rapport 59 4. Database 60
4.1 Entiteit Relatie Diagram 60
4.2 Constraints 61 5. Grafische gebruikersinterface 62 5.1 Scherm mockups 62 5.2 Vormgeving 63 5.2.1 Menustructuur 63 5.3 Validatie invoervelden 65 6. Bronnen 66
1. Inleiding
Om te kunnen afstuderen voor de deeltijdopleiding Informatica, welke ik volg bij Avans Hogeschool, moet ik bij mijn werkgever een afstudeeropdracht uitvoeren in de vorm van een project. Het eindproduct is een volledig functionerende applicatie, welke ontwikkeld zal worden aan de hand van de gekozen softwareontwikkelmethode DSDM. Dit Functioneel Model is het resultaat van de uitvoering van de huidige fase ‘Functionele-modeliteratie’. In dit Functioneel Model worden zowel de functionele als niet-functionele eisen benoemd. Ook komen verschillende aspecten aan bod welke betrekking hebben op deze eisen.
Figuur 12: DSDM-procesdiagram
In paragraaf 2.1 worden de functionele eisen opgesomd, waarna deze vervolgens in paragraaf 2.1.1 worden geprioriteerd middels MoSCoW. Wanneer deze worden gerealiseerd wordt weergegeven in een timeboxing-tabel. In hoofdstuk 3 worden User-cases weergegeven en omschreven van de belangrijkste functionaliteiten van de applicatie. In hoofdstuk 4 staan het ontwerp en andere aanverwante zaken met betrekking tot de database van het te ontwikkelen systeem vermeld. In het daarop volgende hoofdstuk wordt een eerste indruk gegeven van de grafische gebruikersinterface en staan enkele belangrijke details omschreven hiervan. Hoe de beveiliging van de applicatie gerealiseerd gaat worden staat in hoofdstuk 6. Tenslotte zijn in hoofdstuk 7 vermeldingen te vinden van bronnen welke geraadpleegd zijn bij de totstandkoming van dit document.
