IT-PROJECT: CMDB · hoe de code in elkaar zit. Voor dit project zal Model-View-Controller gebruikt...

FACULTEIT ECONOMIE EN BEDRIJFSWETENSCHAPPEN

Hogeschool-Universiteit Brussel Academiejaar 2013 – 2014

Afstudeerrichting: Netwerken & Systemen

IT-PROJECT: CMDB Tim D‘hoe

FACULTEIT BEDRIJFSKUNDE

TOEGEPASTE INFORMATICA

Voorwoord

Dit rapport werd gemaakt in het kader van het behalen van het diploma van Bachelor in de Toegepaste Informatica, studiegebied Handelswetenschappen en Bedrijfskunde aan de Hogeschool-Universiteit Brussel. Waarbij dit rapport aantoont dat het niveau 6 van bachelor gehaald wordt.

Doorheen dit rapport wordt het project gedetailleerd beschreven. Met als doel duidelijk te maken wat het project is, voor wie het is, waarom het nodig is en hoe het zal aangepakt worden. Dit alles met oog op zowel technische als niet-technische lezers.

1

1 INHOUDSOPGAVE

1 Inleiding ......................................................................................................................................... 4

2 Krijtlijnen definieren ..................................................................................................................... 5

2.1 Probleemstelling ................................................................................................................... 5

2.2 Introductie tot de CMDB ..................................................................................................... 5

2.2.1 Definitie .......................................................................................................................... 5

2.2.2 Doel ................................................................................................................................ 5

2.2.3 Onderdelen ................................................................................................................... 6

2.2.4 Best practices ................................................................................................................ 6

2.3 CMDB toegepast op dit project ......................................................................................... 7

2.3.1 Dit project ...................................................................................................................... 7

2.3.2 Toekomstige projecten ................................................................................................ 7

2.4 Gewenste Functionaliteiten ................................................................................................ 7

2.4.1 Functionele eisen .......................................................................................................... 7

2.4.2 Kwaliteitseisen ............................................................................................................... 7

3 Analyse ........................................................................................................................................... 8

3.1 Vorige Toepassing ................................................................................................................ 8

3.1.1 Inleiding.......................................................................................................................... 8

3.1.2 Problemen...................................................................................................................... 8

3.2 Nieuwe toepassing ............................................................................................................... 8

3.2.1 Inleiding.......................................................................................................................... 8

3.2.2 Technologiekeuze......................................................................................................... 9

4 Design .......................................................................................................................................... 13

4.1 Datamodel ........................................................................................................................... 13

4.1.1 Structuur ....................................................................................................................... 13

4.1.2 Inhoud .......................................................................................................................... 13

4.2 GUI ........................................................................................................................................ 14

4.2.1 Gelijkenissen met DSL-applicatie ............................................................................. 14

4.2.2 Schetsen ....................................................................................................................... 14

5 Kwaliteitscontrole ....................................................................................................................... 15

5.1 Datamodel ........................................................................................................................... 15

5.2 Webapplicatie ..................................................................................................................... 15

6 Reflectie & Conclusies ................................................................................................................ 16

6.1 Uitdaging ............................................................................................................................. 16

6.2 Communicatie ..................................................................................................................... 16

2

6.3 Moeilijkheden ...................................................................................................................... 16

6.4 Conclusie .............................................................................................................................. 16

7 Bijlagen ......................................................................................................................................... 17

7.1 Lijst der bijlagen .................................................................................................................. 17

8 Informatiebronnen .......................................................................................................................107

3

1 INLEIDING Dit project wordt in opdracht van het departement “Server Management” van P&V gedaan, een groot verzekeringskantoor gevestigd in Brussel en Antwerpen.

Het moet een bestaande “CMDB” applicatie binnen het bedrijf vervangen door een

efficiëntere, flexibelere en eenvoudig uitbreidbare applicatie. De oude loopt immers tegen

zijn limieten aan en kan moeilijk verder worden uitgebreid.

De functie van deze applicatie is het bijhouden van gedetailleerde informatie over eigendommen van het bedrijf. In dit geval beperken we ons tot eigendommen die met IT te maken hebben, meer bepaald servers.

4

2 KRIJTLIJNEN DEFINIEREN

2.1 PROBLEEMSTELLING Het server management team van P&V Groep heeft een Microsoft Access database, met daarin informatie over al hun servers en bijhorende onderhoudscontracten.

Deze database is na enkele jaren gebruik onoverzichtelijk geworden en zit vol overbodige en ongebruikte velden.

Daarom werd dit project opgestart, het doel is om de Access database om te zetten naar een nieuwe applicatie, namelijk een CMDB. De applicatie moet het mogelijk maken efficiënter te werken, en moet schaalbaar zijn naar de toekomst toe.

2.2 INTRODUCTIE TOT DE CMDB

2.2.1 Definitie

Een CMDB of ‘Configuration Management Database’ is een database waarin we alles met betrekking tot configuratie gaan bijhouden en beheren. Om dit te illustreren nemen we volgend voorbeeld:

Een bedrijf heeft twee servers: in de CMDB houden we voor elk van deze servers gedetailleerde informatie bij, bijvoorbeeld: van welk merk zijn ze, hoeveel geheugen hebben ze en wat is hun functie. Daarnaast vertelt de CMDB ons ook het onderlinge verband tussen deze twee servers (als dit er is), bijvoorbeeld: server 1 is de back-up-server van server 2.

Dit kunnen ook andere elementen zijn dan alleen maar servers, ook een computer, een werknemer of zelfs een gebouw kunnen in een CMDB zitten. Een bepaald element wordt een CI of Configuration Item genoemd in CMDB-terminologie.

Wat in het voorbeeld uitgelegd is, is de kern van de CMDB. Dit is waar het in dit project om draait.

2.2.2 Doel

CMDB is een onderdeel van ITIL (Information Technology Infrastructure Library). ITIL is een verzameling van ‘best practices’ om IT binnen een organisatie te beheren. Elk bedrijf dat dat een IT-afdeling heeft zou in bepaalde mate van ITIL gebruik moeten maken om op een goede manier deze afdeling te runnen.

Daarom is het ook interessant om een CMDB te hebben, aangezien het een centraal punt is om alle informatie van ‘Configuration Items’ te raadplegen en beheren.

Het biedt een duidelijk overzicht van wat een bedrijf bezit en laat toe dit efficiënt te beheren.

5

2.2.3 Onderdelen

In de definitie hebben we de kern van de CMDB besproken, maar er is meer mogelijk met een CMDB dan enkel informatie beheren van CI’s.

Zoals in figuur 1 wordt weergegeven, kan een CMDB worden uitgebreid om te dienen als informatiebron voor bijvoorbeeld een helpdesk. De helpdesk kan bijvoorbeeld de CMDB gebruiken om aan te geven bij welke CI er een probleem is opgetreden.

Voor meer informatie over de CMDB en zijn uitbreidingen, zie bijlage PV008.

2.2.4 Best practices

2.2.4.1 Intelligence Een CMDB moet de onderlinge relaties tussen CI’s begrijpen en de mogelijkheid hebben om de data op verschillende manieren weer te geven.

2.2.4.2 Discovery Een CMDB zou automatisch CI’s moeten kunnen

vinden, dit is uiteraard veel efficiënter dan

manueel alles invoeren.

2.2.4.3 Federation Houd de kern van de CMDB schoon, maak databases voor zaken die niet tot de kern behoren (bijvoorbeeld Service Level Agreements afsplitsen).

2.2.4.4 Change Control Een CMDB moet een revisiegeschiedenis bijhouden van elk CI.

2.2.4.5 Flexibility Een CMDB moet toelaten eenvoudig nieuwe attributen toe te voegen aan bestaande CI’s.

2.2.4.6 Extensibility Een CMDB moet eenvoudig aanpasbaar zijn om nieuwe soorten CI’s toe te voegen.

2.2.4.7 Scalability Een CMDB moet grote hoeveelheden data aankunnen.

Figuur 1 CMDB met zijn mogelijke uitbreidingen

6

2.3 CMDB TOEGEPAST OP DIT PROJECT

2.3.1 Dit project

Zoals aangegeven in het vorige onderdeel, kan een CMDB worden uitgebreid om meerdere taken te vervullen.

In dit project ligt de focus enkel op de Configuration Items met hun onderlinge relaties. De focus ligt niet op de CMDB Extended Data of CMDB Environment (zie figuur 1 op de vorige pagina).

De kern van de CMDB in dit project zal niet alle mogelijke soorten CI’s bevatten, we beperken ons tot servers en alles wat er bij hoort (onderhoudscontracten, werknemers van het bedrijf die iets met de servers te maken hebben).

2.3.2 Toekomstige projecten

Er moet rekening worden gehouden met het feit dat de CMDB mogelijk in de toekomst uitgebreid wordt.

Niet alleen nieuwe soorten CI’s moeten gemakkelijk toegevoegd kunnen worden, maar ook moet het huidige project toelaten om op een eenvoudige manier te integreren met zaken uit de CMDB Environment (bijvoorbeeld helpdesk).

2.4 GEWENSTE FUNCTIONALITEITEN

2.4.1 Functionele eisen

Dit zijn de voornaamste functionaliteiten die de applicatie moet bevatten:

Men kan servers weergeven, toevoegen, aanpassen en verwijderen.

Men kan rapporten maken binnen de applicatie.

Er is voldoende security.

Data kan geëxporteerd worden naar Microsoft Excel.

Heeft dezelfde look & feel als een bestaande interne applicatie (DSL-applicatie).

Voor een complete lijst van functionaliteiten kan bijlage PV000 (PID) en bijlage PV001 (Requirements Analysis) worden geraadpleegd.

2.4.2 Kwaliteitseisen

De applicatie is future-proof

Ontwikkeld met CMDB best practices in het achterhoofd nl.: o Flexibility o Extensibility o Scalability o Federation o Intelligence o Discovery

De applicatie is gebruiksvriendelijk

De applicatie is OS onafhankelijk

Voor een complete lijst van kwaliteitseisen kan bijlage PV000 (PID) en bijlage PV001 (Requirements Analysis) worden geraadpleegd.

7

3 ANALYSE

3.1 VORIGE TOEPASSING

3.1.1 Inleiding

De vorige toepassing was een Microsoft Access toepassing die verschillende rapporten, query’s en forumlieren bevatte. Deze applicatie had hetzelfde doel als de nieuwe toepassing

namelijk: servers met hun bijhorende informatie, contracten, mensen, enz... beheren.

3.1.2 Problemen

3.1.2.1 Database Structuur Het datamodel werd in de levensloop van de toepassing uitgebreid. Om geen problemen te creëren met bestaande data, werd het datamodel soms niet op de beste manier aangepast.

Daarnaast zijn er in sommige tabellen veel velden voorzien, die dan later nooit gebruikt werden.

3.1.2.2 Formulieren & Query’s De naamgeving van sommige tabellen, formulieren en query’s toont niet altijd duidelijk aan waarvoor ze dienen. Er

zijn ook query’s die overbodig geworden zijn of vervangen

door een verbeterde versie.

3.1.2.3 Besluit Algemeen kunnen we stellen dat de toepassing te vol staat met allerhande query’s en formulieren, waardoor de

efficiëntie afneemt.

Voor meer informatie over de vorige toepassing, gelieve bijlage PV002 te bekijken.

3.2 NIEUWE TOEPASSING

3.2.1 Inleiding

De nieuwe toepassing zal rekening houden met de fouten van zijn voorganger. Daarom is er extra aandacht besteed aan gebruiksvriendelijkheid (de toepassing moet eenvoudig te gebruiken zijn en blijven), schaalbaarheid (de toepassing moet veel data aankunnen) en flexibiliteit (velden moeten eenvoudig toegevoegd of verwijderd kunnen worden).

Daarnaast worden natuurlijk ook alle requirements van de klant in acht genomen, zoals vermeld in 2.4 Gewenste Functionaliteiten.

Figuur 2 Voorbeeld van onduidelijke naamgeving in vorige toepassing

8

3.2.2 Technologiekeuze

3.2.2.1 Webapplicatie

3.2.2.1.1 Inleiding Zoals vermeldt in 2.4 Gewenste Functionaliteiten verwacht de klant dat de applicatie OS onafhankelijk is. Door deze requirements kan er geen gewone desktop applicatie gebruikt worden. Het is in dit geval beter om een webapplicatie te maken, aangezien dit op elk apparaat gebruikt kan worden.

3.2.2.1.2 Programmeertaal Voor de applicatie kunnen we gebruik maken van talen als PHP, Java en ASP.NET. Dit zijn allemaal talen, die geschikt zijn om webapplicaties mee te maken.

Elke taal biedt specifieke voordelen en nadelen:

PHP o Veel gebruikt op het internet o Krachtig o Moeilijker schaalbaar

Java o Veelgebruikt in het bedrijfsleven o Commerciële ondersteuning o Krachtig o Schaalbaar

ASP.NET (Microsoft) o Veelgebruikt in het bedrijfsleven o Commerciële ondersteuning o Krachtig o Schaalbaar o Eenvoudiger om Microsoft services te implementeren (bv Active Directory). o Serversoftware is niet gratis

In dit project heeft ASP.NET de beste troeven aangezien het bedrijf al werkt met ASP.NET. Er zijn dus al personen aanwezig binnen het bedrijf die kennis van de taal hebben en bijgevolg de applicatie kunnen onderhouden.

Daarnaast is er ook geen extra kost, omdat het bedrijf reeds een ASP.NET server heeft.

Ten slotte is het duidelijk dat de andere talen minder voordelen bieden, omdat men nog iemand zou moeten opleiden vooraleer de applicatie onderhouden kan worden. Dit kost veel.

Voor een uitgebreidere vergelijking tussen de verschillende programmeertalen gelieve bijlage PV003 te bekijken.

9

3.2.2.1.3 Ontwerppatroon Bij het ontwikkelen van de webapplicaties moet ook een ontwerppatroon gekozen worden. Een ontwerppatroon zorgt voor een structuur binnen de code. Dit is nodig om het overzichtelijk te houden en om er voor te zorgen dat andere ontwikkelaars sneller begrijpen hoe de code in elkaar zit.

Voor dit project zal Model-View-Controller gebruikt worden, dit ontwerppatroon laat eenvoudig schaalbaarheid en het testen van de code toe, dit ten koste van de complexiteit.

Voor meer informatie over de mogelijke ontwerppatronen en hun voordelen, gelieve bijlage PV004 te bekijken.

Figuur 3 De werking van het Model-View-Controller patroon

10

3.2.2.2 Database

3.2.2.2.1 Server Als database software kunnen we kiezen uit verschillende pakketten die elke hun eigen voordelen bieden:

Microsoft SQL Server o Schaalbaar o Performant o Geavanceerd

MySQL o Gratis o Eenvoudige functionaliteiten o Veelgebruikt voor webtoepassingen

Oracle SQL o Schaalbaar o Performant o Geavanceerd

In dit project heeft Microsoft SQL Server de beste troeven. Het kan veel data aan en laat toe in de toekomst eenvoudig uit te breiden zonder te moeten denken aan verlies van performantie. Daarnaast is het geen extra investering meer voor het bedrijf, aangezien ze al gebruik maken van Microsoft SQL Server.

Voor een geavanceerde vergelijking tussen de verschillende database-pakketten, gelieve bijlage PV003 te bekijken.

3.2.2.2.2 Structuur Tegenover de oude toepassing gebruiken we hier een object-georiënteerd i.p.v. relationeel datamodel. Dit geeft enkele voordelen, nl.:

Universeel datamodel: zowel de webtoepassing als de database gebruiken dezelfde structuur. Dit vermindert de complexiteit en laat toe om later eenvoudiger aanpassingen te doen in de applicatie.

Object-Oriëntatie zorgt er voor dat uitbreiding later gemakkelijker is (wanneer men bijvoorbeeld een nieuw soort CI wil toevoegen).

Figuur 4 logo's van de vergeleken database-pakketten

11

3.2.2.3 Beveiliging Beveiliging is heel belangrijk, ook in een interne bedrijfsapplicatie. Er kunnen immers altijd intern in het bedrijf kwaadwillenden zijn.

Op aanvraag van de klant, gaat de beveiliging werken met Microsofts Active Directory voor het verlenen van toegang tot de applicatie.

In de praktijk komt het er op neer dat wanneer een bepaalde gebruiker naar de applicatie browset, hij automatisch wordt ingelogd en rechten krijgt. Dit komt omdat de applicatie weet wie er op die bepaalde computer is ingelogd en op die manier weet welke rechten deze persoon hoort te krijgen.

Normaal inloggen met gebruikersnaam en wachtwoord zal ook beschikbaar zijn, dit om te voorkomen dat er geen toegang meer tot de applicatie is wanneer de Active Directory server offline is.

12

4 DESIGN

4.1 DATAMODEL

4.1.1 Structuur

Zoals eerder aangegeven zal dit project een object-georiënteerd datamodel gebruiken.

De structuur zorgt er voor dat er slechts één model nodig is waarop code en database gebaseerd zijn. Dit vermindert het werk dat nodig is om in latere projecten zaken toe te voegen of te verwijderen (extra velden, nieuwe CI’s).

Daarnaast is het model zodanig gemaakt dat het toe laat om gemakkelijk nieuwe types CI’s toe te voegen zonder het model helemaal te moeten herwerken. Op de figuur hieronder wordt dat uitgebeeld. Een nieuw type aanmaken is gewoon een nieuwe tabel aanmaken en deze linken aan ConfigrationItem

4.1.2 Inhoud

De inhoud van het datamodel is deels een vertaling van de structuur van de oude applicatie, minus zaken die overbodig zijn geworden.

Kort samengevat bevat de structuur alles wat nodig is om:

o Virtuele en fysieke servers te beheren o Back-ups van servers te beheren o Onderhoudscontracten te beheren o Personen te beheren

Figuur 5 Deel van het data model, geeft CI types weer.

13

Voor een volledig overzicht van de structuur, gelieve bijlage PV009 te bekijken.

4.2 GUI

4.2.1 Gelijkenissen met DSL-applicatie

De opdrachtgever eist dat het design van de webapplicatie in dezelfde stijl ligt als de interne DSL-applicatie.

Figuur 6 Hoofdpagina DSL-applicatie

Voor meer screenshots en uitleg over de DSL-applicatie, gelieve bijlage PVEXTERN001 te bekijken.

4.2.2 Schetsen

Figuur 7 Hoofdscherm van de te ontwikkelen toepassing

14

Figuur 8 Scherm om server aan te passen of toe te voegen

Voor meer prototypes, gelieve document PV010 te bekijken.

5 KWALITEITSCONTROLE

5.1 DATAMODEL Het datamodel werd reeds geverifieerd en getest. Op deze manier zijn er al verschillende fouten opgelost. Tijdens de implementatie zal er nog meer getest worden.

5.2 WEBAPPLICATIE De kwaliteit van de webapplicatie wordt gegarandeerd door methodologisch te werken. Er werden reeds Use Cases gemaakt, die aantonen hoe bepaalde requirements gerealiseerd kunnen worden.

Tijdens de implementatie zullen er nog extra methodes gebruikt worden om code te testen en zodoende te repareren.

Voor meer informatie over kwaliteitscontrole en Use Cases, gelieve document PV000, PV005, PV006 en PV007 te bekijken.

15

6 REFLECTIE & CONCLUSIES

6.1 UITDAGING Dit project was voor mij een uitdaging, omdat ik met twee nieuwe dingen geconfronteerd werd.

Enerzijds het feit dat ik als afstudeerrichting netwerken & system heb, maar toch moet programmeren. Dit dan nog in een nieuwe taal (ASP.NET).

Daarnaast moet ik ook iets maken wat ik daarvoor nog niet kende, namelijk een CMDB.

6.2 COMMUNICATIE De communicatie met de opdrachtgever verliep zeer goed. Ik ben verschillende keren naar het bedrijf geweest om een aantal dingen te bespreken (requirements te weten proberen komen, enz...).

Daarnaast was er de communicatie met de stagebegeleider, die was ook in orde. Al hebben we slechts twee maal contact gehad. Ik had meer contact met de docenten waar ik les van heb. Dit komt vooral omdat zij konden helpen bij technische problemen.

6.3 MOEILIJKHEDEN Omdat dit de eerst keer was dat ik een echt project moest doen volgens PRINCE2, was het in het begin nogal moeilijk. Vooral het PID duurde nogal lang, dit kwam omdat ik eerst nog allemaal moest begrijpen wat er nodig is om een project succesvol te doen.

Daarnaast waren er wat moeilijkheden met het datamodel, de eerste paar versies waren te generiek. Deze werkten wel, maar het was gevaarlijk om er snel fouten mee te maken.

Na wat meer onderzoek over wat een CMDB is, ben ik overgestapt naar een object-georiënteerd datamodel. Het moeilijke was om een balans te vinden tussen een generieke of te specifieke oplossing te hebben, het model moest immers uitbreidbaar zijn. Dit heeft mij het meeste tijd gekost.

6.4 CONCLUSIE Het project is uitdagend genoeg, ik moet redelijk wat nieuwe dingen leren. Daarnaast heb ik geleerd dat er veel fout kan gaan in een project en dat alles trager gaat dan ik verwacht.

16

7 BIJLAGEN

7.1 LIJST DER BIJLAGEN

DOCUMENT NUMMER NAAM

PV000 Project Initiation Document PV001 Requirements Analysis PV002 Previous Application Analysis PV003 Technology Selection PV004 ASP.NET Design Pattern Selection PV005 Actors PV006 Use Cases PV007 CMDB Use Case Diagram PV008 Requirements for a generic CMDB PV009 Data Model PV010 GUI Prototype PVEXTERN001 DSL-application screenshots PV011 Project Plan PV012 Time Sheets PV013 Meeting Minutes PV014 CV PV015 Presentation

17

1

Requirements Analysis

1 CONTENTS 2 About this document ................................................................................................................... 1

3 Requirements Engineering .......................................................................................................... 2

2 ABOUT THIS DOCUMENT Project P&V SCMDB Document Number PV001 Status Draft Current Revision 20131106D

Changelog Removed normal user Past Revisions Changelog

20131105D Adding user roles 20131030D Initial Creation

This document contains the requirements for the project.

18

2

3 REQUIREMENTS ENGINEERING

Id Title Type State Priority Owner

BREQ-140 The application is secure and prevents unauthorized access. Business Requirement Approved High

BREQ-141 The application has decent performance. Business Requirement Approved Normal

BREQ-144 The application has to be user friendly. Business Requirement Approved High

BREQ-151 Application is OS independent. Business Requirement Approved High

BREQ-152 The application is low cost. Business Requirement Approved Normal

BREQ-153 Application can be maintained by existing personnel. Business Requirement Approved Very High

BREQ-154 Application is always available. Business Requirement Approved Normal

BREQ-160 The application is designed with future expandability in mind. Business Requirement Approved Normal

BREQ-161 The application is designed with CMDB best practices in mind. Business Requirement Approved Normal

FEAT-106 A user can search the database easily. Feature Draft High

FEAT-107 A user can log in. Feature Approved High

FEAT-108 A user can log out. Feature Approved Normal

FEAT-109 An administrative user can modify server information. Feature Approved Very High

19

3

FEAT-110 An administrative user can add a server. Feature Approved Very High

FEAT-111 An administrative user can remove a server. Feature Approved High

FEAT-112 An administrative user can create a report. Feature Approved Very High

FEAT-115 An administrative user can modify the layout of a specific CI-type. Feature Draft Normal

FEAT-122 A user can export a report as CSV. Feature Approved Normal

FEAT-124 A user can export one ore more server's detailed information as CSV. Feature Approved High

FEAT-126 A user can create an advanced SQL search query easily. Feature Approved Normal

FEAT-133 An administrative user can delete a report. Feature Approved Normal

FEAT-134 An administrative user can modify a report. Feature Approved Normal

FEAT-135 A user can view a report. Feature Approved Normal

FEAT-139 A user can view server information. Feature Approved Normal

20

1

Pre-existing application analysis

1 CONTENTS

2 About this document ................................................................................................................... 1

3 Document Summary ..................................................................................................................... 2

4 Structural Overview ...................................................................................................................... 3

5 Structural Analysis ......................................................................................................................... 4

5.1 Structure Detail ..................................................................................................................... 4

5.2 Weak Points ........................................................................................................................... 4

6 Database Usage ............................................................................................................................ 5

6.1 Forms & Queries ................................................................................................................... 5

6.2 Weak Points ........................................................................................................................... 5

7 What to keep ................................................................................................................................. 5

7.1 Requirements Summary ....................................................................................................... 5

7.2 Structure ................................................................................................................................. 6

7.2.1 Overview ........................................................................................................................ 6

7.2.2 Explanation .................................................................................................................... 7

7.3 Conclusion ............................................................................................................................. 7

7.3.1 Application ..................................................................................................................... 7

7.3.2 Database structure ....................................................................................................... 7

2 ABOUT THIS DOCUMENT Project P&V SCMDB Document Number PV002 Status Final Revision 20140104F Changelog Document finalization Past Revisions Changelog

20131105D Initial Creation 20131231D Added database usage chapter

This document contains information about the previous (S)CMDB solution that was used at P&V.

The analysis consists of a breakdown of the database structure of the file SCMDB.mdb and a quick look at how the database is used. This is a Microsoft Access database.

21

2

Based on this analysis it will be decided which parts of the structure will be kept in the new application.

3 DOCUMENT SUMMARY The database structure needs to be reworked, it’s also important to not make the same mistakes again in the new application.

22

3

4 STRUCTURAL OVERVIEW

Figuur 1 Database structure of existing application

23

4

5 STRUCTURAL ANALYSIS The current database is an RDBMS in Microsoft Access.

5.1 STRUCTURE DETAIL TABLE DESCRIPTION SERVERS_PHYSICAL Contains physical information about the

servers (serial num., location,...). SERVERS Contains non-physical, often variable

information about the servers (server name, domain name,...).

SERVERS_VMWARE Contains information about virtual VMware servers.

SUPPORTCONTRACTS Contains the support SupportID for every server.

SUPPORT Contains information about Support Companies.

MEM CONFIG Contains RAM details of the servers. DATASTORE ? COMPANIES Table containing company names. VLAN Contains information about VLANís SUPPLIERS Contains information about suppliers LUN Contains information about the LUNs for

each server CONTACTS Contains information about the contacts for

each server. APPLICATIONS Contains information about the

applications/role of every server NETWORKTOPOLOGY Contains network information DISK CONFIG Contains disk information per server BACKUPINFO Contains backup information per server NICCONFIG Contains NIC information per server SERVICESTOMONITOR Contains services that are monitored per

server OS Contains operating system information per

server SHARES Contains information about the shares that

exist on every server

5.2 WEAK POINTS The current structure presents problems, namely:

Tables don’t always have their FK’s referenced the correct PK. Many fields remain unused

24

5

6 DATABASE USAGE

6.1 FORMS & QUERIES Several forms and queries are used to maintain the database. Unfortunately there are a lot of them, many are not used or are replaced with newer versions.

6.2 WEAK POINTS Unused queries and forms Reduced efficiency because of the many irrelevant queries and

forms

7 WHAT TO KEEP

7.1 REQUIREMENTS SUMMARY For this project the customer has the following requirements:

Performance is not a critical factor (only internal usage, for only one department).

Application has to scale well (CMDB can be extended in the future).

Application needs to be user friendly.

For detailed information about the requirements for this project, please check document PV001.

25

6

7.2 STRUCTURE

7.2.1 Overview

Figuur 2 Existing database, with fields and tables marked depicting what to keep and what not in the new data structure

26

7

7.2.2 Explanation This image show the field that will be incorporated in the new application in green. The tables with red crosses are no longer necessary. This has been selected based on interviews with the client.

7.3 CONCLUSION

7.3.1 Application Due to the database being in Microsoft Access, the following problems arise:

Does not scale well Bad performance in large databases Hard limits prevent database expansion Drop in user friendliness when database grows larger

This can be resolved by using different database software instead of Microsoft Access.

7.3.2 Database structure The database structure needs to revised, currently there are a lot of unused fields and tables that clutter the database.

Another problem is that the current structure prevents expansion, which is required for the new CMDB.

We can conclude the structure itself cannot be reused in the new application.

27

1

Technology Selection



4 Requirements ................................................................................................................................ 2

4.1 Requirements Summary ....................................................................................................... 2

4.2 Application Type ................................................................................................................... 2

4.3 Company Resources ............................................................................................................. 2

5 Web Application Languages ....................................................................................................... 3

5.1 Comparison Table ................................................................................................................ 3

5.2 Chosen Language ................................................................................................................. 3

6 Database Software ....................................................................................................................... 4

6.1 Comparison Table ................................................................................................................ 4

6.2 Chosen Database Server ..................................................................................................... 4

7 Bibliography .................................................................................................................................. 4


20131105D Initial Creation 20131231D Added comparison tables

This document contains a comparison between technologies that could be usable in this project. Based on that comparison and the needs of the customer, a decision will be made on what technologies will be used.

3 DOCUMENT SUMMARY The application will be an ASP.NET web application, using SQL Server as database server.

28

2

4 REQUIREMENTS

4.1 REQUIREMENTS SUMMARY For this project the customer has the following requirements:

Application is OS independent. Application is always available. Low cost (no additional costs preferred). Performance is not a critical factor (only internal usage, for only one department). Application can be maintained by existing personnel. Application has to scale well (CMDB can be extended in the future).

For detailed information about the requirements for this project, please check document PV001.

4.2 APPLICATION TYPE Because of the first two requirements, the application can only be a Java application (platform independence), or a web application.

Mobile devices are becoming more popular. This has to be kept in mind for future expansion of the application. Because of this Java would be a bad choice. Mobile devices do not have Java support.

The only remaining option is a web application.

4.3 COMPANY RESOURCES Within the company there is already a CMDB related application deployed (DSL-application).

This is an ASP.NET application. ASP.NET is therefore preferred as there is already someone within the company that has experience with it.

This also reduces costs, because there is already an ASP.NET server available for use. The DSL-application uses SQL Server as its database server. For consistency en budgetary reasons, it would be wise to also use SQL Server for this project.

29

3

5 WEB APPLICATION LANGUAGES

5.1 COMPARISON TABLE PHP ASP.NET JSP Scalability +++ ++++ ++++ Easy of learning +++ ++ ++

Features +++ ++++ ++++ Performance ++++ ++++ +++ Support Community ++++ ++++ ++++

5.2 CHOSEN LANGUAGE ASP.NET and JSP are best for this project. PHP is less interesting because it is less used in the professional world. Choosing PHP would make it harder to find someone capable of maintaining / upgrading the application.

Since the company already works with ASP.NET, this will be the best choice for this project.

30

4

6 DATABASE SOFTWARE

6.1 COMPARISON TABLE

6.2 CHOSEN DATABASE SERVER For this project, it is important to remember that the project is laying the foundation for a complete CMDB. Therefore SQL Server or Oracle would be good choices. Primarily because these are great for expandability and scalability.

Since the company already has SQL Server, it is the most cost effective to use this for the project.

7 BIBLIOGRAPHY A comparison of PHP vs ASP.net, Performance, Cost, Scalability, Support and Complexity. (2013, 12

31). Retrieved from Comentum: http://www.comentum.com/php‐vs‐asp.net‐

comparison.html

Access vs SQL Server vs MySQL vs Oracle. (2013, 12 31). Retrieved from Find The Best:

http://database‐management‐systems.findthebest.com/compare/24‐26‐30‐36/Access‐vs‐

Microsoft‐SQL‐Server‐vs‐MySQL‐vs‐Oracle

Johnlim. (2004, 07 01). High Performance, High Scalability PHP is a Lie. Retrieved from PHP Lens:

http://phplens.com/phpeverywhere/?q=node/view/55

Performance benchmarking ‐ PHP, ASP, JSP, Coldfusion. (2013, 12 31). Retrieved from LinuxDocs:

http://www.linuxdocs.org/HOWTOs/PHP‐HOWTO‐13.html

MySQL Microsoft Access SQL Server Oracle SQL Performance +++ + ++ ++++ Feature Richness

++ + ++++ ++++

Scalability +++ + +++ +++ Price ++++ +++ ++ + Support Community Commercial (SLA) Commercial (SLA) Commercial (SLA)

31

1

ASP.NET Design Pattern Selection



4 Why use a design pattern? .......................................................................................................... 2

5 Available patterns ......................................................................................................................... 2

5.1 WinForms ............................................................................................................................... 2

5.1.1 Advantages .................................................................................................................... 2

5.2 MVC ........................................................................................................................................ 2

5.2.1 Advantages .................................................................................................................... 2

6 Project needs ................................................................................................................................. 3

7 Bibliography .................................................................................................................................. 3

2 ABOUT THIS DOCUMENT Project P&V SCMDB Document Number PV003 Status Final Revision 20140105F Changelog Document Finalization Past Revisions Changelog

20131215D Initial Creation

This document contains a comparison between the possible design patterns that can be used in creating an ASP.NET application.

3 DOCUMENT SUMMARY Model-View-Controller (MVC) will be used as the design pattern for this project.

32

2

4 WHY USE A DESIGN PATTERN? Design patterns are important because of the following reasons:

Other people will understand your code better (universal way of doing things) Future readiness (you know how good your pattern scales, performs, ...)

5 AVAILABLE PATTERNS

5.1 WINFORMS

5.1.1 Advantages Development supports state: Gives the illusion that a web application is aware of what

the user has been doing, similar to Windows applications. I.e. Makes 'wizard' functionality a little bit easier to implement. Web forms does a great job at hiding a lot of that complexity from the developer.

Rapid Application Development (RAD): The ability to just 'jump in' and start delivering web forms. This is disputed by some of the MVC community, but pushed by Microsoft. In the end, it comes down to the level of expertise of the developer and what they are comfortable with. The web forms model probably has less of a learning curve to less experienced developers.

Larger control toolbox: ASP.NET Web Forms offers a much greater and more robust toolbox (web controls) whereas MVC offers a more primitive control set relying more on rich client-side controls via jQuery (Javascript).

Mature: It's been around since 2002 and there is an abundance of information with regards to questions, problems, etc. Offers more third-party control - need to consider your existing toolkits.

(Biggest advantage to using ASP.Net MVC vs web forms, 2013)

5.2 MVC (MODEL-VIEW-CONTROLLER)

5.2.1 Advantages Separation of concerns (SoC): From a technical standpoint, the organization of code

within MVC is very clean, organized and granular, making it easier for a web application to scale in terms of functionality. Promotes great design from a development standpoint.

Easier integration with client side tools (rich user interface tools): More than ever, web applications are increasingly becoming as rich as the applications you see on your desktops. With MVC, it gives you the ability to integrate with such toolkits (such as jQuery) with greater ease and more seamless than in Web Forms.

Search Engine Optimization (SEO) Friendly / Stateless: URL's are more friendly to search engines (i.e. mywebapplication.com/users/ 1 - retrieve user with an ID of 1 vs mywebapplication/users/getuser.aspx (id passed in session)). Similarly, since MVC is stateless, this removes the headache of users who spawn multiple web browsers from the same window (session collisions). Along those same lines, MVC adheres to the stateless web protocol rather than 'battling' against it.

Works well with developers who need high degree of control: Many controls in ASP.NET web forms automatically generate much of the raw HTML you see when a page is rendered. This can cause headaches for developers. With MVC, it lends itself

33

3

better towards having complete control with what is rendered and there are no surprises. Even more important, is that the HTML forms typically are much smaller than the Web forms which can equate to a performance boost - something to seriously consider.

Test Driven Development (TDD): With MVC, you can more easily create tests for the web side of things. An additional layer of testing will provide yet another layer of defense against unexpected behavior.

(Biggest advantage to using ASP.Net MVC vs web forms, 2013)

6 PROJECT NEEDS As stated in previous documents, the CMDB application need to be able to scale. The application has to have to capability to grow exponentially. Besides that is testing also important.

There is only one pattern that allows there two things and that is MVC. Therefore MVC will be used for this project.

7 BIBLIOGRAPHY Biggest advantage to using ASP.Net MVC vs web forms. (2013, 04 08). Opgehaald van

StackOverflow: http://stackoverflow.com/questions/102558/biggest-advantage-to-using-asp-net-mvc-vs-web-forms

Galipeau, G. (2008, 04 04). Choosing a UI Pattern (MVC, MVP, and ASP.Net MVC). Opgehaald van GregGalipeau : http://www.greggalipeau.com/2008/04/04/choosing-a-ui-pattern-mvc-mvp-and-aspnet-mvc/

Sukesh, M. (2013, 02 07). WebForms vs. MVC. Opgehaald van Code Project: http://www.codeproject.com/Articles/528117/WebForms-vs-MVC

34

1

Actors



4 Actors ............................................................................................................................................. 2

4.1 List ........................................................................................................................................... 2

4.2 Detail ...................................................................................................................................... 3

4.2.1 Administrative user ....................................................................................................... 3

4.2.2 Read-only User .............................................................................................................. 3



This document contains a list of the different types of people that will be using the application, so called “Actors”.

Each “Actor” has a different set of responsibilities/actions that he can do within the application (Goals).

3 DOCUMENT SUMMARY There are two actors, namely:

Read-only User Administrative User

35

2

4 ACTORS

4.1 LIST ID Name Description Goals

ACTR-103 Administrative User A user with full CRUD capabilities. This user can do everything.

Add server information. Edit server information. Delete server information. Add reports. Edit reports. Delete reports. Manage application settings.

ACTR-102 Read-Only User A user with limited access, can only view information.

Limited CRUD capabilities.

View server information. View reports.

36

3

4.2 DETAIL

4.2.1 Administrative user ID: ACTR-103

Use Cases where this actor is a Primary Actor

Authenticate User UC-116

Create a server UC-118

Use Simple Search UC-120

Use Advanced Search UC-121

Modify a server UC-128

Create a report UC-129

Modify a report UC-130

View a report UC-131

Delete a report UC-132

View a server UC-137

Delete a server UC-138

Export selection as CSV UC-164

4.2.2 Read-only User ID: ACTR-102

Use Cases where this actor is a Primary Actor

Authenticate User UC-116





Export selection as CSV UC-164

37

1

Use Cases


3 Authenticate User ........................................................................................................................... 4

3.1 Description (Goal in context) ................................................................................................... 4

3.2 Primary Actors ......................................................................................................................... 4

3.3 Pre conditions .......................................................................................................................... 4

3.4 Main Flow‐of‐Events................................................................................................................ 4

3.5 Alternate Flows ....................................................................................................................... 4

3.6 Post conditions ........................................................................................................................ 4

3.7 Linked Requirements ............................................................................................................... 5

4 Create a server ................................................................................................................................ 6

4.1 Description (Goal in context) ................................................................................................... 6

4.2 Primary Actors ......................................................................................................................... 6

4.3 Pre conditions .......................................................................................................................... 6

4.4 Main Flow‐of‐Events................................................................................................................ 6

4.5 Alternate Flows ....................................................................................................................... 6

4.6 Post conditions ........................................................................................................................ 7

4.7 Linked Requirements ............................................................................................................... 9

5 Modify a server.............................................................................................................................. 10

5.1 Description (Goal in context) ................................................................................................. 10

5.2 Primary Actors ....................................................................................................................... 10

5.3 Pre conditions ........................................................................................................................ 10

5.4 Main Flow‐of‐Events.............................................................................................................. 10

5.5 Alternate Flows ..................................................................................................................... 10

5.6 Post conditions ...................................................................................................................... 11

5.7 Linked Requirements ............................................................................................................. 13

6 Create a report .............................................................................................................................. 14


6.2 Primary Actors ....................................................................................................................... 14

6.3 Pre conditions ........................................................................................................................ 14


6.5 Alternate Flows ..................................................................................................................... 14

38

2

6.6 Post conditions ...................................................................................................................... 15


7 Modify a report ............................................................................................................................. 16


7.2 Primary Actors ....................................................................................................................... 16

7.3 Pre conditions ........................................................................................................................ 16


7.5 Alternate Flows ..................................................................................................................... 16

7.6 Post conditions ...................................................................................................................... 17


8 Delete a report .............................................................................................................................. 18


8.2 Primary Actors ....................................................................................................................... 18

8.3 Pre conditions ........................................................................................................................ 18


8.5 Alternate Flows ..................................................................................................................... 18

8.6 Post conditions ...................................................................................................................... 18


9 View a report ................................................................................................................................. 20


9.2 Primary Actors ....................................................................................................................... 20

9.3 Pre conditions ........................................................................................................................ 20


9.5 Alternate Flows ..................................................................................................................... 20

9.6 Post conditions ...................................................................................................................... 20


10 Use Simple Search ..................................................................................................................... 22


10.2 Primary Actors ....................................................................................................................... 22

10.3 Pre conditions ........................................................................................................................ 22


10.5 Alternate Flows ..................................................................................................................... 22

10.6 Post conditions ...................................................................................................................... 22


11 Use Advanced Search ................................................................................................................ 24

11.1 Primary Actors ....................................................................................................................... 24

39

3


11.3 Alternate Flows ..................................................................................................................... 24

11.4 Post conditions ...................................................................................................................... 24

12 View a server ............................................................................................................................. 26


12.2 Primary Actors ....................................................................................................................... 26

12.3 Pre conditions ........................................................................................................................ 26


12.5 Alternate Flows ..................................................................................................................... 26


13 Delete a server .......................................................................................................................... 28


13.2 Primary Actors ....................................................................................................................... 28


13.4 Alternate Flows ..................................................................................................................... 28

13.5 Post conditions ...................................................................................................................... 28


14 Export selection as CSV ............................................................................................................. 30


14.2 Primary Actors ....................................................................................................................... 30

14.3 Pre conditions ........................................................................................................................ 30


14.5 Alternate Flows ..................................................................................................................... 30

14.6 Post conditions ...................................................................................................................... 30




40

4

3 AUTHENTICATE USER

UC-116

3.1 DESCRIPTION (GOAL IN CONTEXT)

This Use Case documents the process of a user logging in to the application.

3.2 PRIMARY ACTORS

Administrative User [ACTR-103] Read-Only User [ACTR-102]

3.3 PRE CONDITIONS Active Directory is up and running.

3.4 MAIN FLOW‐OF‐EVENTS 1. Employee accesses login page

2. Contact Active Directory

3. Throw 403 error.

4. Use Case ends with Failure.

3.5 ALTERNATE FLOWS

3a. Is employee in SCMDB-CRUD group?

1. Grant user administrative privileges

2. Use Case ends with Success.

3b. Is employee in SCMDB-RO group?

1. Grant user read-only privileges


3.6 POST CONDITIONS Success end condition

‐User is granted access to the application

Failure end condition

‐User gets a 403 error

Minimal Guarantee

‐The minimum guarantee ensures that no unauthorized access is possible to the application, to

protect the company from abuse of the contained information.

41

5

3.7 LINKED REQUIREMENTS

ID Title

BREQ-140 The application is secure and prevents unauthorized access. For maximal security, Active Directory is a good choice.

FEAT-107 A user can log in.

42

6

4 CREATE A SERVER

UC-118


This Use Case documents the process of creating a new "Server" CI.

4.2 PRIMARY ACTORS

Administrative User [ACTR-103]

4.3 PRE CONDITIONS An administrative user must be logged on.

The database connection must be up and running.

4.4 MAIN FLOW‐OF‐EVENTS 1. The Administrative User clicks "Add new server"

2. The Administrative User gives the server a name

3. Application gives warning "Name already used"

4. Application asks "Load record of existing server?"

5. Set "Server Name" backcolor to Orange

6. Continue from step 1. of 3a. Is name unique?.

4.5 ALTERNATE FLOWS

3a. Is name unique?

1. Loop

1.1. The Administrative User fills in additional basic info

1.2. Verify server input

2. Until ( Validation Success )


5a. Did the user click "OK"?

1. Load existing record


43

7


-A new (empty) server object will be created


-A server object is not created, everything remains unchanged.

Minimal Guarantee

-The transaction will be 100% complete or 0% (ACID db transaction)

44

9


ID Title

FEAT-110 An administrative user can add a server.

46

10

5 MODIFY A SERVER

UC-128


This Use Case documents the process of modifying the data of a specific "Server" CI.

5.2 PRIMARY ACTORS


5.3 PRE CONDITIONS An Adminstrative user is logged on.

The connection to the database is up and running.

At least one "server" exists in the database.

5.4 MAIN FLOW‐OF‐EVENTS 1. Administrative User clicks a server.

2. Detailed server information is shown.

3. Loop

3.1. Administrative User makes changes.

3.2. Administrative User clicks "Save" button.

3.3. Verify server input

4. Until ( Validation Success )

5. Send query to database.

6. Changes saved.


5.5 ALTERNATE FLOWS

6a. Database returns error?

1. Changes discarded.


47

11


-Data of a "Server" CI is successfully modified.


-Data remains unchanged.

Minimal Guarantee

- Database transaction is ACID

48

12

49

13


ID Title

FEAT-109 An administrative user can modify server information.

50

14

6 CREATE A REPORT

UC-129


This Use Case documents the process of creating a new report.

6.2 PRIMARY ACTORS


6.3 PRE CONDITIONS An administrative user is logged on.

The connection to the database is available.

6.4 MAIN FLOW‐OF‐EVENTS 1. Administrative User clicks "New..." button

2. A popup windows opens

3. Use Visual SQL Tool [UC-125]

4. Display error


6.5 ALTERNATE FLOWS

4a. Returns valid query string?

1. Display new report

2. Discard report


4a2a. User clicks save?

1. Send query to database

2. Refresh reports list


4a2a2a. Database returns error?

1. Display error message


51

15


-A new report is created.


-Nothing is created.

Minimal Guarantee

- Database transaction is ACID and the query used to build the report is valid.


ID Title

FEAT-112 An administrative user can create a report.

52

16

7 MODIFY A REPORT

UC-130


This Use Case documents the process of modifying a report.

7.2 PRIMARY ACTORS


7.3 PRE CONDITIONS At least one report exists. An administrative user is logged on. The database connection is up and running.

7.4 MAIN FLOW‐OF‐EVENTS 1. Administrative User selects a report

2. Administrative User clicks "Edit..." button

3. A popup window opens


5. Report not modified


7.5 ALTERNATE FLOWS

5a. Returns valid query string?

1. Display new report

2. Discard changes


5a2a. User clicks save?


2. Refresh report


5a2a2a. Database returns error?

1. Display error message.


53

17


-Data of a "Server" CI is successfully modified.


-Data remains unchanged.

Minimal Guarantee

- Database transaction is ACID.


ID Title

FEAT-134 An administrative user can modify a report.

54

18

8 DELETE A REPORT

UC-132


This Use Case documents the process of deleting a report.

8.2 PRIMARY ACTORS


8.3 PRE CONDITIONS At least one report exists.

An administrative user is logged on.

The connection to the database is available.

8.4 MAIN FLOW‐OF‐EVENTS 1. View a report [UC-131]

2. Administrative User clicks "Delete" button.

3. Warning is displayed.

4. Report not deleted.


8.5 ALTERNATE FLOWS

4a. User confirmed delete?


2. Refresh reports window.


4a2a. Database returns error?



8.6 POST CONDITIONS Success end condition - The report is deleted. Failure end condition - Nothing is deleted. Minimal Guarantee - Database transaction is ACID.

55

19


ID Title

FEAT-133 An administrative user can delete a report.

56

20

9 VIEW A REPORT

UC-131


This Use Case documents the process of viewing a report.

9.2 PRIMARY ACTORS


9.3 PRE CONDITIONS A user is logged on.

Database connection is up and running.

There is at least one report defined.

9.4 MAIN FLOW‐OF‐EVENTS 1. A user selects a report.


3. Report is opened in same window.


9.5 ALTERNATE FLOWS


1. Display error.



- A report is displayed.


- Nothing is displayed.

Minimal Guarantee

- The information that is displayed is complete and correct.

57

21


ID Title

FEAT-135 A user can view a report.

58

22

10 USE SIMPLE SEARCH

UC-120

10.1 DESCRIPTION (GOAL IN CONTEXT) This Use Case documents the process of using the search feature in simple mode.

10.2 PRIMARY ACTORS



The connection to the database is up and running.

10.4 MAIN FLOW‐OF‐EVENTS 1. The user types his query in the 'search' field

2. The user presses 'enter' or the 'search' button


4. Display results

10.5 ALTERNATE FLOWS

3a. Is search field empty?

1. Set search field's backcolor to red


4a. Is the resultset empty?

1. Display "No Results"



-The search will return a set of results.


-The search will return an error.

Minimal Guarantee

-

59

23


ID Title

FEAT-106 A user can search the database easily.

60

24

11 USE ADVANCED SEARCH

UC-121

11.1 PRIMARY ACTORS


11.2 MAIN FLOW‐OF‐EVENTS 1. User clicks "Advanced" button

2. A popup windows opens




4a. Returns query?


2. Display results





4a2b. Is the resultset empty?

1. Display "No Results"



‐


‐

Minimal Guarantee

‐

61

25

62

26

12 VIEW A SERVER

UC-137

12.1 DESCRIPTION (GOAL IN CONTEXT) This Use Case documents the process of viewing a "Server" CI's detailed information.

12.2 PRIMARY ACTORS



The database connection is up and running.

There is at least one "Server" CI defined.

12.4 MAIN FLOW‐OF‐EVENTS 1. User clicks a server.


3. Display detailed server information.


12.5 ALTERNATE FLOWS 3a. Database returns error?



Post conditions Success end condition

- A report is displayed.


- Nothing is displayed.

Minimal Guarantee

- The information that is displayed is complete and correct.

63

27


ID Title

FEAT-139 A user can view server information.

64

28

13 DELETE A SERVER

UC-138

13.1 DESCRIPTION (GOAL IN CONTEXT) This Use Case documents the process of deleting a "Server" CI and all it's data.

13.2 PRIMARY ACTORS


13.3 MAIN FLOW‐OF‐EVENTS 1. View a server [UC-137]

2. Administrative User clicks the "Delete" button.

3. Cancel action



3a. User clicks confirm?

1. Send query to server

2. Return to previous window






- A "Server" CI and all its data is deleted.


- Nothing is deleted.

Minimal Guarantee

- Database transaction is ACID.

65

29


ID Title

FEAT-111 An administrative user can remove a server.

66

30

14 EXPORT SELECTION AS CSV

UC-164

14.1 DESCRIPTION (GOAL IN CONTEXT) This Use Case documents the process of exporting one or more server's detailed information as CSV.

14.2 PRIMARY ACTORS



At least one server CI is present in the database.

14.4 MAIN FLOW‐OF‐EVENTS 1. User selects one or more servers in the list.

2. User presses "Export" button.


4. Generate CSV.

5. CSV file is downloaded to user's computer.







- A CSV file is downloaded to the user's computer.


- An error message is displayed.

Minimal Guarantee

- The exported information is 100% complete.

67

31


ID Title

FEAT-124 A user can export one or more server's detailed information as CSV.

68

1

CMDB Use Case Diagram

1 CONTENTS CMDB Use Case Diagram ................................................................................................................... 1

1 Contents ......................................................................................................................................... 1

2 About this document ................................................................................................................... 1

2.1 CMDB ..................................................................................................................................... 2

2.2 Actors on the Diagram ......................................................................................................... 3

2.3 Use Cases on the Diagram .................................................................................................. 3



This document contains a Use Case diagram depicting all possible Use Cases with their actors.

69

2

2.1 CMDB UCD-143

70

3

2.2 ACTORS ON THE DIAGRAM Administrative User ACTR-103

Read-Only User ACTR-102

2.3 USE CASES ON THE DIAGRAM Authenticate User UC-116

Create a report UC-129

Create a server UC-118

Delete a report UC-132

Delete a server UC-138

Modify a report UC-130

Modify a server UC-128





71

1

Requirements for a generic CMDB



4 What is a CMDB? .......................................................................................................................... 2

4.1 Definition ................................................................................................................................ 2

4.2 Functions of a CMDB ........................................................................................................... 2

4.3 Best Practices ........................................................................................................................ 3

4.3.1 Intelligence .................................................................................................................... 3

4.3.2 Discovery ........................................................................................................................ 3

4.3.3 Federation ...................................................................................................................... 3

4.3.4 Change Control ............................................................................................................. 3

4.3.5 Flexibility ........................................................................................................................ 3

4.3.6 Extensibility .................................................................................................................... 4

4.3.7 Scalability ....................................................................................................................... 4

5 What do we need from a CMDB in this project? ..................................................................... 4

5.1 Functions ................................................................................................................................ 4

5.2 Future ..................................................................................................................................... 4

6 Bibliography .................................................................................................................................. 4



This document

3 DOCUMENT SUMMARY

72

2

4 WHAT IS A CMDB?

4.1 DEFINITION CMDB is part of ITIL, which is a collection of best practices for managing IT within on organization. The core task of the CMDB is to

4.2 FUNCTIONS OF A CMDB A CMDB has more functions than just

Process Supported Functions Incident Management Incidents can be prioritized more accurately

based on the relationships between affected CIs. Incidents can be resolved faster, because the entire CI information for each user is visible.

Problem Management Detailed information for problem analysis is available.

Change Management Support for the analysis of potential ramifications for the production environment after changes take place.

Release Management Availability of information for release planning and execution, so that rollouts do not have a negative effect on the business.

73

3

(iET Solutions, 2006)

4.3 BEST PRACTICES

4.3.1 Intelligence

Transform your data into meaningful information. A CMDB should automatically understand and navigate arbitrarily complex relationships between dissimilar CIs and have the ability to represent that data in multiple views that are relevant to individual decision makers throughout your organization.

4.3.2 Discovery

Determine what you have. A CMDB should identify all the CIs in your IT repertoire without the costs and errors associated with manual discovery.

4.3.3 Federation

Manage data throughout your enterprise. A CMDB should access data where it lives, pulling appropriate data, regardless of each sourceís vendor or performance level, into a unified view and provide transparent read access.

4.3.4 Change Control

Manage change in dynamic environments. Because IT is dynamic and change is constant, a CMDB should include versioning capabilities to recognize and address change.

4.3.5 Flexibility

Change what you need, when you need to. A CMDB should provide a platform for growth and should be easily modifiable to accommodate new data sources, tools, and applications; more business processes; and additional and changing CI attributes and relationships.

Configuration Management The CMDB is the database in which the IT infrastructure is recorded and described delivering a detailed model of the IT infrastructure for all processes.

Service Level Management Availability of information about the CIs that support an IT service. Without this data, SLAs cannot be thoroughly created and adhered to.

Financial Management for IT Services CI information is enhanced by financial data which are necessary for the cost and service billing.

Availability Management Measuring and control of the availability of the Configuration Items and delivery of information to identify weak points.

IT Service Continuity Management Based on the CIs, emergency contingency plans and baselines are created, which should be available at the alternative location.

Capacity Management The CMDB delivers information for capacity planning and tuning measures.

Security Management The CMDB includes classifications from security management for trustworthiness, integrity and availability, and provides information for risk management.

74

4

4.3.6 Extensibility

Grow with your business. The CMDB data model should be extensible to easily support the addition of new CI class types such as process controllers in manufacturing lines and radiology and other diagnostic machinery in hospitals.

4.3.7 Scalability Handle organizational size and complexity. A CMDB should be able to store and manage a virtually unlimited number of CIs and their relationships without negatively impacting system performance.

(Connor, 2008)

5 WHAT DO WE NEED FROM A CMDB IN THIS PROJECT?

5.1 FUNCTIONS The CMDB only needs to allow basic functionality, namely CIs and their relationships.

5.2 FUTURE The CMDB must be able to expand with new CI-types and links with other databases. We must at this moment respect the best practices to be able to do that.

6 BIBLIOGRAPHY bmc software. (2006). What Do You Need from a Configuration Management Database

(CMDB)?

Connor, J. (2008). Choosing the Right CMDB.

iET Solutions. (2006). CMDB in 5 Steps: A Project Guideline for Implementing a Configuration Management Database.

Messineo, D. A. (2009, April). Myths of the Configuration Management Data Base (CMDB).

75

1

Data Model


3 Document summary ..................................................................................................................... 1

4 Structural Overview ...................................................................................................................... 2

5 Structure Explanation .................................................................................................................. 3

5.1 Modularity ............................................................................................................................. 3

5.2 Adaptability ........................................................................................................................... 3

5.3 Mapping ................................................................................................................................ 3

6 Included functionality .................................................................................................................. 3

7 Conclusion ..................................................................................................................................... 3



This document contains the proposed data model for the application and database.

3 DOCUMENT SUMMARY The model is object-oriented and allows for easily adding new CI-types in the future. Supports only the server CI-type and its requirements.

76

2

4 STRUCTURAL OVERVIEW

Can't read this? Scan to view the digital version of the model

77

3

5 STRUCTURE EXPLANATION

5.1 MODULARITY The data model is designed with modularity in mind. To achieve this more easily it is object-oriented. It allows to easily add new types of CIs.

The class “ConfigurationItem” is an abstract class and can therefore not be instantiated. It serves however as a base class for all future types of CIs.

As specified in previous documents, this project will only implement the “Server” CI type, and all associating types (Person and Support).

5.2 ADAPTABILITY Using an object-oriented model allows for easy adapting of the application. When fields need to be added in the future, only one model needs to be changed instead of two (when working with a relational database).

5.3 MAPPING The object-oriented approach, allows the application to seamlessly interact with the database. This database is generated automatically based on this data model. Mapping ensures that fields and tables of the data model match those of the database.

6 INCLUDED FUNCTIONALITY The data model included all tables and field necessary to comply with the requirements.

The model allows for:

Maintaining virtual and physical servers o OS o RAM o Storage o Networking o CPU o Applications

Maintaining backups of servers o Partition based

Maintaining support companies and contracts Maintaining people

7 CONCLUSION Please check “3 Document Summary”.

78

1

GUI Prototype


3 Main Screen ................................................................................................................................... 2

3.1 Filter On ................................................................................................................................. 2

3.2 Filter Off ................................................................................................................................. 2

4 Adding/Modifying a server ......................................................................................................... 3

5 Search Results ............................................................................................................................... 4



This document contains GUI prototypes of the web application.

79

2

3 MAIN SCREEN

3.1 FILTER ON

3.2 FILTER OFF

80

3

4 ADDING/MODIFYING A SERVER

81

4

5 SEARCH RESULTS

82

DSL-Applicatie Screenshots & Uitleg CONTENTS 1 About this document .............................................................................................................................. 1

2 Screenshots with explanation ................................................................................................................ 2

1 ABOUT THIS DOCUMENT

Project P&V SCMDB Document Number PVEXTERN001 Status Final Revision UNKNOWN-EXTERNAL DOCUMENT Remark This document is in Dutch.

This document shows screenshots of the DSL-application and some explanation about its

behavior.

83

2 SCREENSHOTS WITH EXPLANATION

“Home page”

Geeft overzicht (alfabetisch gesorteerd)

Voor applicaties kan alles wat in een entry zit, worden gedisplayed op lijn. Voor servers kan dit niet, hier zal een 1e aantal gegevens moeten worden

getoond met de mogelijkheid om een detail window te kunnen openen.

D.m.v. “Filter” kunnen filters worden gezet waardoor een beperkt aantal rijen wordt getoond.

D.m.v. “Add” wordt een window geopend voor toegevoegen van een nieuwe entry (zie verder bij ADD windows).

D.m.v. “Edit” openen van een selectie scroll down menu (zie verder bij EDIT-selectie).

84

Bij scrollen op home

page

Voor selectie

van release

overzicht

Zie verder

“Overzicht

release”

85

Subwindow “overzicht release”

Voor “Edit” van

deze entry

87

“ADD window” voor invoeren van een nieuwe application-entry (de “add”-button is van de print screen gevallen)

88

EDIT-selectie: pop-up met scroll down menu van alle beschikbare entries, dan een entry te selecteren voor edit.

89

“Filter” selecties

Filter geeft dit

window

90

Definition Phase Generic Design Phase

Sep‐Oct Oct‐Nov

Documentation

PID

Project Plan

Project Planning

Risk Book

Scope Definition

ERD

Test Data Set

Business Requirements Definition

Functional Specification

Functional Test Scenario

Non Functional Test Scenario

Interface Specification

Use Cases

GUI Prototype

Source Code

System Test Report

System Test Scenario

Unit Test Report

Unit Test Scenario

Functional Test Report

Non Functional Test Report

Project Plan P&V (S)CMDB

91

Design Phase Implementation Phase

Nov‐Dec Feb‐Jun Jun

Backup & Monitor Tool Phase

92

1

Time Sheets


3 Timesheet ...................................................................................................................................... 2



This document gives detailed information about the time spent on this project.

93

2

3 TIMESHEET Tijd (uur) Dag Omschrijving Locatie Uitvoerder Klant

2 23/09/2013 Informatie over IT‐Project HUB Tim D'hoe P&V

2 24/09/2013 Informatie over IT‐Project HUB Tim D'hoe P&V

4 25/09/2013 Projecten zoeken HUB Tim D'hoe P&V

2 26/09/2013 Bedrijven contacteren HUB Tim D'hoe P&V



2 1/10/2013 Voorbereiden presentatie P&V HUB Tim D'hoe P&V




3 7/10/2013 Meeting met HIG over Quickscan Campus Gezinswetenschappen, BRU Tim D'hoe P&V

4 8/10/2013 Meeting bij P&V over CMDB project P&V, Koningsstraat 150 ,BRU Tim D'hoe P&V

4 9/10/2013 PID CMDB + Verslag meeting maken HUB Tim D'hoe P&V

2 10/10/2013 Start timesheets + PID HUB Tim D'hoe P&V

4 11/10/2013 PID HUB Tim D'hoe P&V

2 14/10/2013 PID Thuis Tim D'hoe P&V


4 16/10/2013 PID + req analysis HUB Tim D'hoe P&V

2 17/10/2013 Requirements analysis HUB Tim D'hoe P&V

4 18/10/2013 Denken over datamodel + PID Thuis Tim D'hoe P&V

2 21/10/2013 Analyse vorige database + PID Thuis Tim D'hoe P&V

2 22/10/2013 Datamodel schets maken Thuis Tim D'hoe P&V

4 23/10/2013 Bedrijf contacteren + datamodel HUB Tim D'hoe P&V

2 24/10/2013 Denken over mogelijke technologie voor applicatie. HUB Tim D'hoe P&V

2 29/10/2013 Meeting met HUB begeleider HUB Tim D'hoe P&V

94

3

2,5 30/10/2013 Werken aan verschillende deliverables Thuis Tim D'hoe P&V

5 31/10/2013 Werken aan verschillende deliverables, analyse vorige applicatie Thuis Tim D'hoe P&V

3 4/11/2013 Opnieuw nadenken over requirements, meeting voorbereiden Thuis Tim D'hoe P&V

2 5/11/2013 Aanpassingen PID HUB Tim D'hoe P&V

2 6/11/2013 Meeting P&V Thuis Tim D'hoe P&V

4 7/11/2013 Verslag meeting + documentatie Thuis Tim D'hoe P&V

4 8/11/2013 Werken aan documentatie deliverables Thuis Tim D'hoe P&V

2 12/11/2013 PID aanpassen Thuis Tim D'hoe P&V

4 13/11/2013 Werken aan datamodel HUB Tim D'hoe P&V

2 14/11/2013 Werken aan datamodel HUB Tim D'hoe P&V

4 15/11/2013 Werken aan datamodel Thuis Tim D'hoe P&V

2 16/11/2013 Datamodel finaliseren en testen Thuis Tim D'hoe P&V

2 18/11/2013 Voorbereiden meeting Thuis Tim D'hoe P&V

2 19/11/2013 Meeting P&V P&V, Koningsstraat 150 ,BRU Tim D'hoe P&V

4 20/11/2013 ASP leren HUB Tim D'hoe P&V



2 25/11/2013 ASP leren Thuis Tim D'hoe P&V

2 26/11/2013 ASP leren Thuis Tim D'hoe P&V

4 27/11/2013 PID aanpassen aan feedback + ASP leren HUB Tim D'hoe P&V


2 29/11/2013 Timesheets controleren en insturen Thuis Tim D'hoe P&V

2 2/12/2013 Deliverables Thuis Tim D'hoe P&V

2 3/12/2013 Meeting Yvan Rooseleer, data model herwerken HUB Tim D'hoe P&V





2 10/12/2013 Data Model Thuis Tim D'hoe P&V

95

4















4 25/12/2013 Data Model & Deliverables Thuis Tim D'hoe P&V











4 5/01/2014 Hoofdtekst Thuis Tim D'hoe P&V


4 7/01/2014 Meetings HUB begeleider HUB Tim D'hoe P&V



96

5




5 13/01/2014 Meeting P&V P&V, Koningsstraat 150 ,BRU Tim D'hoe P&V










6 23/01/2014 Hoofdtekst & Presentatie & Deliverables Thuis Tim D'hoe P&V 330,5

97

1

Meeting Minutes


3 Minutes ........................................................................................................................................... 2

3.1 6 November 2013 .................................................................................................................... 2

3.2 19 November 2013 .................................................................................................................. 3



This document contains the summary of all the meetings with the client.

98

2

3 MINUTES

3.1 6 NOVEMBER 2013

Meeting: 6 nov 2013 General Info Location: P&V Groep, Koningsstraat 150, Brussels People present: Luc Van den Berg, Tim D’hoe, Frank Vansweevelt

Topics Further details about requirements Discussing structure of old application Discussing features of new application

Summary of meeting Basic (new) requirements of the application are:

Search functionality within the data Ability to create and save queries, to allow flexible report generating. Authentication is required, but only a read-only and administrative user are the only

roles required. Revision support is optional (nice to have).

Follow up Next meeting will be planned after the creation of the database structure, so it can be reviewed in group.

99

3

3.2 19 NOVEMBER 2013

Meeting: 19 nov 2013 General Info Location: P&V Groep, Koningsstraat 150, Brussels People present: Luc Van den Berg, Tim D’hoe, Frank Vansweevelt

Topics Discussing planning Discussing new database structure

Summary of meeting Deadlines have been explained to the customer.

Developed database structure was approved.

Follow up Several document will he sent to the customer:

PID Database model

100

PV014 - Curriculum Vitae

Personalia

Naam: Tim D’hoe

Adres: Velodroomstraat 212

1770 Liedekerke

Telefoon: +32496822683

Email: [email protected]

Geboortedatum: 08 juni 1993

Geslacht: man

Nationaliteit: Belg

Rijbewijs: B

Opleidingen

sep 2011 - heden Bachelor, Toegepaste Informatica Afstudeerrichting: Systemen en netwerken

Hogeschool-Universiteit Brussel, Brussel

Werkervaring

aug 2013 – sep 2013 HUB, Brussel Functie: Jobstudent Informaticaproject Werkzaamheden: Ontwikkelen van Quickscan-tool (enquêtetool) in Oracle APEX

aug 2012 - aug 2012

Antargaz, Vilvoorde Functie: Jobstudent Werkzaamheden: Verhuis IT-afdeling

jul 2010 - jul 2010

jul 2009 - jul 2009

FOD Kanselarij, Brussel

Functie: Jobstudent ICT Helpdesk

Werkzaamheden: Wissen en imagen van pc’s

Overige

Talen: Nederlands, vloeiend

Engels, vloeiend

Frans, redelijk

Computerkennis: C#, zeer goed Java, goed

Oracle SQL, zeer goed

SQL Server, zeer goed

Windows Server, goed

Cisco IOS, zeer goed

Cisco Configuration Professional, goed

Cisco ASDM, goed

URL: LinkedIn

101

http://be.linkedin.com/in/timdhoe

http://be.linkedin.com/in/timdhoe

23/01/2014

1

IT-Project: CMDB

Tim D’hoe

Wie?

Afdeling “Server Management” van P&V Verzekeringen

Groot bedrijf

Antwerpen & Brussel

102

23/01/2014

2

Wat?

Toepassing voor het beheren van informatie over servers

CMDB

Web toepassing ASP.NET & SQL Server

CMDB?

ITIL

KERN: beheren eigendommen van een bedrijf Servers, Mensen, Gebouwen, … Configuration Items (CI)

Uitbreiding naar bv. service desk

103

23/01/2014

3

CMDB in dit project

Beperkt tot kern van CMDB

Enkel “Servers” als type Configuration Item

Wat is er gebeurd?

Requirements analyse

Analyseren vorige applicatie Problemen

ASP.NET bijschaven

104

23/01/2014

4

Wat is er gebeurd?

Analyse “Wat is een CMDB, wat heb ik nodig?”

Data Model maken Focus op uitbreidbaarheid

GUI prototypes

GUI Prototype

Hoofdscherm

105

23/01/2014

5

GUI Prototype

o Invoerscherm

Moeilijkheden

Data Model generiek maken

PID

106

8 INFORMATIEBRONNEN

A comparison of PHP vs ASP.net, Performance, Cost, Scalability, Support and Complexity. (2013, 12

31). Opgehaald van Comentum: http://www.comentum.com/php-vs-asp.net-

comparison.html

Access vs SQL Server vs MySQL vs Oracle. (2013, 12 31). Opgehaald van Find The Best:

http://database-management-systems.findthebest.com/compare/24-26-30-36/Access-vs-

Microsoft-SQL-Server-vs-MySQL-vs-Oracle

Biggest advantage to using ASP.Net MVC vs web forms. (2013, 04 08). Opgehaald van StackOverflow:

http://stackoverflow.com/questions/102558/biggest-advantage-to-using-asp-net-mvc-vs-

web-forms

bmc software. (2006). What Do You Need from a Configuration Management Database (CMDB)?

Connor, J. (2008). Choosing the Right CMDB.

Galipeau, G. (2008, 04 04). Choosing a UI Pattern (MVC, MVP, and ASP.Net MVC). Opgehaald van

GregGalipeau : http://www.greggalipeau.com/2008/04/04/choosing-a-ui-pattern-mvc-mvp-

and-aspnet-mvc/

iET Solutions. (2006). CMDB in 5 Steps: A Project Guideline for Implementing a Configuration

Management Database.

Johnlim. (2004, 07 01). High Performance, High Scalability PHP is a Lie. Opgehaald van PHP Lens:

http://phplens.com/phpeverywhere/?q=node/view/55

Messineo, D. A. (2009, April). Myths of the Configuration Management Data Base (CMDB).

Performance benchmarking - PHP, ASP, JSP, Coldfusion. (2013, 12 31). Opgehaald van LinuxDocs:

http://www.linuxdocs.org/HOWTOs/PHP-HOWTO-13.html

Sukesh, M. (2013, 02 07). WebForms vs. MVC. Opgehaald van Code Project:

http://www.codeproject.com/Articles/528117/WebForms-vs-MVC

107

IT-PROJECT: CMDB · hoe de code in elkaar zit. Voor dit project zal Model-View-Controller gebruikt...

Documents

Transcript of IT-PROJECT: CMDB · hoe de code in elkaar zit. Voor dit project zal Model-View-Controller gebruikt...