mi a szerepe az informatikai - mmk.hu · pdf filemi a szerepe az informatikai projekt...

Mi a szerepe az informatikai projekt ellenőrnek?

• A projekt előrehaladásának támogatásaElőre-haladás

• A jogszabályi és szervezeti biztonsági előírások betartásának biztosítása a projektben

• Az információbiztonság megvalósulásának ellenőrzése a projektben

Biztonság ellenőrzés

• Projekt dokumentáció véleményezése

• Termék dokumentáció véleményezése

• Elkészült rendszer ellenőrzése

Minőség-biztosítás

1

Mik az informatikai projektellenőr feladatai?

• Projekt előrehaladás támogatása

• Részvétel a projekt megbeszéléseken, felmerülő kérdések esetén tanácsadás

• Tanácsadás és támogatás a projekt döntéseiben

• Projektvezető(k) szakmai támogatása, a projektben felmerülő bármilyen informatikai jellegű kérdés megválaszolásában

• Az elkészült projektterv véleményezése

• Projektmegbeszélések jegyzőkönyveinek/emlékeztetőinek véleményezése

Projekt

• Követelményspecifikáció véleményezése, jogszabályi megfelelőség vizsgálata, eltérések jelzése, megoldási javaslatok megfogalmazása

• Logikai és fizikai rendszertervek véleményezése, szakmai kiegészítési javaslatok megtétele, előírt követelményektől való eltérések jelzése és korrekciós javaslatok megfogalmazása

• Tesztelési tervek véleményezése, az elkészített tesztelési tervek megfelelőek-e a rendszer átadás-átvételéhez, a követelményeknek teljesülésének igazolásához (funkcionális, integrációs, biztonsági és teljesítmény tesztelés)

• Dokumentumok véleményezése, az elkészített műszaki dokumentációk (felhasználói leírás, üzemeltetői leírás) véleményezése, annak vizsgálata, hogy megfelelő minőségű és terjedelmű-e az átvételhez (munkafolyamat orientált, részletezettsége megfelelő)

Dokumen-táció

2

•Iparági gyakorlat és szabványok szerinti megvalósulás vizsgálata: a tervezett és megvalósított rendszer összevetése a műszaki dokumentációban hivatkozott IT iparági gyakorlat szerinti megoldásokkal

•Gyártói előírások betartásának vizsgálata: a telepített eszközök megfelelő üzemeléshez előírt telepítési feltételek alkalmazásának vizsgálata, eltérések jelzése

•Az előírt számszerűsített követelmények teljesítésének ellenőrzése a műszaki dokumentációban előírt követelményeknek a tesztek során

•Műszaki szakértői feladatok ellátása a teszteknél és átvételi eljárásoknál, tervektől való eltérések dokumentálása

•A tesztforgatókönyv végrehajtásának ellenőrzése, az egyes lépések eredményének hitelesítése, hibák és eltérések esetén azok dokumentálása

Szakértői támogatás

Mik az informatikai projektellenőr feladatai?

3

Tartalom

2017.12.07. MMK-Informatikai projekt ellenőr képzés 4

• Elemző Adatbázisok

• Az adattárházak komponensei • Adatmodell

• Adatbázis-kezelő

• ETL

• Front-end : BI eszköz

• Operatív döntéstámogatás: kimenő interfészek

• Adatbányász eszköz

• Meta-adat kezelés és „data governance”

• Jogosultság-kezelés, adat biztonság

• Egy kis kitekintés: Klasszikus adattárházak és Big Data Architektúrák

• Az adattárház projekt főbb elemei

• Agilis módszerek alkalmazása az adattárház projektekben

• Az adattárház projektek sikerességének alapjai

Elemző adatbázisok


• A tranzakciós rendszerek működésének „melléktermékei” az adatok. Ez a vállalat „az adatvagyona”. Az tranzakciós adatok felhasználása : VIR, MI és egyéb elemzések

• Más funkció

• Más típusú adatbáziskezelés

• Más adatmodell

• Más hardver környezet

OLTP vsElemző

adatbázisok

Informatika

A vállalati adatvagyon részei


BIG DATA

WEBPetabytes

CRMTerabytes

GigabytesERP

Exabytes

INCREASING Data Variety and Complexity

User Generated Content

Mobile Web

SMS/MMS

Sentiment

External Demographics

HD Video

Speech to Text

Product/Service Logs

Social Network

Business Data Feeds

User Click Stream

Web Logs

Offer History A/B Testing

Dynamic Pricing

Affiliate Networks

Search Marketing

Behavioral Targeting

Dynamic FunnelsPayment Record Support Contacts

Customer TouchesPurchase

Detail

Purchase Record

Offer Details

Segmentation

DECREASING Value Density in the Data

Az adattárházak komponensei


Az adattárházak adatarchitektúrája


StageSystem of Records/

DWAggregációk Adatpiacok

Források

Az adattárházak adatarchitektúrája


STAGE• forrásrendszerrel megegyező tárolási struktúra• forrásadatok többnyire napi táblapartíciókban• adatfogadás vagy beszerzés • forrásadatok változtatásmentes archiválása• Teljes újratöltés lehetősége

DW• egységes üzleti adatmodell• helyettesítő kulcs képzése• forrás természetes kulcsainak tárolása• történeti adattárolás• elsődleges, egyedi és idegen kulcsok beállítása• forrásrendszeri fix értékkészletek egységes tárolása• forrásoldali fizikai törlés kezelése• szótár-, törzs-, kapcsoló- és esemény típusú táblák • technikai mezők: OBJ_TIPUS, FORRAS_AZON_1…5

DM• helyettesítő kulcs megtartása• különböző aggregáltsági szint több rétegen keresztül• újrafuttathatóság a folyamatos bővítések miatt• aggregátumok üzleti paraméterezés alapján • helygazdálkodás kérdése, visszamenőleges adattárolás

Adatpiac és adattárház: Adatarchitektúrák


Informatika

Adatpiac és adattárház : adatarchitektúrák – tervezési szempontok


Informatika

• Elemzési célok sokrétűsége• Az elemzési adatbázis szerepe a vállalati architektúrában• A felhasználók széleskörűsége, típusai, száma• Az elemzendő adatok (forrásrendszerek ) száma• Adatbázis méret, history• ..stb

Az adattárházak komponensei: adatmodell


• Relációs vs. dimenzionális• „Kész adatmodellek” vs. „custom developed”• Az adatmodell karbantartása„házon belülre” vs. szállítónál• Adatmodellező team : rend vs. szűk keresztmetszet• CASE eszköz használata – metaadat kezelés

Az adattárházak komponensei: adatbázis kezelés


Egyszeri bulk insertNo updateSelectIdőkezelésParticionálásPárhuzamos felhasználásReal-time igényIndex kezelés Index vs full table scanJogosultság kezelésTuningolás, adminisztráció

Shared everything vs shared nothing vs in memoryAppliance megközelítés

Az adattárházak komponensei: ETL


ETL eszközök vs „kézzel írt kódok”- ODI - Informatica- IBM DataStage- SAS - Talend…stb- „Custom developed”

Tervezési szempontok – meta-adat kezelésCASE eszközök használata: Enterprise Architect, PowerdesignerÜtemező modul

ETL eszköz kiválasztás szempontjai:- funkcionalitás- ár

- szakemberek elérhetősége



- ETL folyamat minősége függÉpített adatmodell minőségétőlMappelés minőségétőlBetöltési folyamatvezérlés és naplózás teljességétől



• Fejlesztő eszköz független formalizált tervezés• Egységes meta adatok képzése• Egységes adatmodellre és kulcsolási mechanizmusra épülő mappelés• Futtatható kód generálás az adatbázisban ill. interface-en keresztül • A generálási folyamat hátterét egy adatbázis objektumokból álló alkalmazás adja,

ami a paraméterezésnek megfelelő mappingeket állít elő.• History képzése :

•egyedi kulcs alapú history képzés standard mezők felhasználásával•history kezelt mezők meghatározása automatikusan - dictionary alapján•céltáblával azonos szerkezetű munkatáblák használata

• Fizikai mapping a logikai mapping alapján könnyen elkészíthető• DW töltése egyszerűbb• DM töltése aggregáltsági szinttől függően több lépésben valósítható meg• Mapping logikák egymásba ágyazhatók• Bonyolultabb forráslekérdezések nézetbe rendezhetők• Generált kód kézi továbbfejlesztése kizárja a központi meta adattár további használatát• Újraindítható kódok



A tervezés előtt a fizikai modell ismeretén kívül szükséges a betöltés szabványainak és névkonvencióinak definiálása.Adatbázis objektumokból álló generálási folyamat háttér, háromszintű paraméterezés:

-Alapadatok definiálása1.Map neve, csoportja2.Céltábla és tulajdonosa, alias3.Töltés típusa:

DELTA/FULLHistory képzés típusa

4.SQL paraméterezés/hintek-Forrástáblák és kapcsolatok definiálása

1.Forrás táblák, tulajdonosok, aliasok2.Forrásként használt táblák kapcsolási feltételei:

JOINHalmazműveletekDISTINCTAnalitikus függvények használata

3.Filterek megadása4.SQL paraméterezés (hintek)5.Automatikus forrás struktúra forgatások – tipikusan DM töltéskor aktuális és history adatok együttes használata (ACT_HIST_FL = ’I’)

-Mezőszintű mappelés1.Forrás-cél mezőpárok2.History képzés egyedi kulcs alapján3.Helyettesítő kulcs képzése szekvenciából egységes rövidnevek alapján 4.Lookup kapcsolatok egyszerű paraméterezése forrás objektumok és idegen kulcsok alapján

Az adattárházak komponensei: Operatív döntéstámogatás –kimenő interfészek


i) Bejövő interfészek : file, „db-link”, „connectors”, SOA megközelítés szerepe.

Szabványok kialakítása

ii) Kimenő interfészek : illeszkedés a SOA architektúrába

Adattárház funkciók vs. Core rendszer funkciók:• „A DWH túlnő az „eredeti” terjedelmén

• Rugalmasabban lehet fejleszteni mint a Core rendszereket• Integrált adatok szükségesek• Historikus adatok szükségeke• Integrált és historikus adatok szükségesek

• Vállalati szintű „adat architektúra”• Rövid távú határidők vs. „rend”

Az adattárházak komponensei: BI -eszköz


Az adattárházak komponensei: adatbányászat


Az adattárházak komponensei: meta-adat kezelés, adatminőség, data governance


i) Átláthatóság – üzleti meta-adatokii) Értékkészletek és hierarchiák karbantartásaiii) Auditálhatóság – technikai meta-adatokiv) Adatminőség – automatikus ellenőrzések / hibák javításav) Meta-adat kezelési architektúra -- rajzvi) Data governance – az adattárházakat menedzselő szervezet és folyamatok szerepe


Meta-adat repository

Target Adatmodell

Forrás adatmodell

Üzleti definíciók

Adatminőségi szabályok

Mapping szabályok

ETL eszköz ETL program

Adatminőség ellenőrzés

Info portál

Ütemezési meta-adatok

Ütemező eszköz


Product Key = Product Key

Customer_Key = Customer_Key

Geography_Key = ShipTo_Address_Key

Geography_Key = BillTo_Address_Key

ProductSubCategory_Key =

ProductSubCategory_Key

Product Key = Product Key

Geography_Key = Geography_Key

DateKey = OrderDate_Key

DateKey = DueDate_Key

DateKey = ShipDate_Key

SalesLT.Dim_Geography

Geography_Key

City

StateProvince

CountryRegion

PostalCode

meta_ValidFrom_Date

meta_ValidTo_Date

meta_Status_Flag

...

numeric(10)

nvarchar(30)

nvarchar(50)

nvarchar(50)

nvarchar(15)

datetime

datetime

tinyint

<pk>

SalesLT.Dim Customer

Customer_Key

CustomerID

Geography_Key

NameStyle

Title

FirstName

MiddleName

LastName

Suffix

CompanyName

SalesPerson

EmailAddress

Phone

PasswordHash

PasswordSalt

AddressLine1

AddressLine2

meta_ValidFrom_Date

meta_ValidTo_Date

meta_Status_Flag

...

numeric(10)

int

numeric(10)

bit

nvarchar(8)

nvarchar(50)

nvarchar(50)

nvarchar(50)

nvarchar(10)

nvarchar(128)

nvarchar(256)

nvarchar(50)

nvarchar(25)

varchar(128)

varchar(10)

nvarchar(60)

nvarchar(60)

datetime

datetime

tinyint

<pk>

<fk>

SalesLT.Dim ProductCategory


ProductSubCategoryID

ProductSubCategory_Name

ProductCategory_Name

meta_ValidFrom_Date

meta_ValidTo_Date

meta_Status_Flag

...

numeric(10)

int

nvarchar(50)

nvarchar(50)

datetime

datetime

tinyint

<pk>

<ak>

SalesLT.Fact ProductModel Description

ProductDescription Key

Product Key

Culture

Description

...

numeric(10)

numeric(10)

nchar(6)

nvarchar(400)

<pk>

<fk>

SalesLT.Fact SalesOrder

SalesOrder_Key

SalesOrderID

SalesOrderDetailID

Product Key

Customer_Key

ShipTo_Address_Key

BillTo_Address_Key

OrderDate_Key

DueDate_Key

ShipDate_Key

OrderQty

UnitPrice

UnitPriceDiscount

LineTotal

RevisionNumber

Status

OnlineOrderFlag

SalesOrderNumber

PurchaseOrderNumber

AccountNumber

ShipMethod

CreditCardApprovalCode

SubTotal

TaxAmt

Freight

TotalDue

Comment

meta_LastModification_Date

meta_Status_Flag

...

numeric(10)

int

int

numeric(10)

numeric(10)

numeric(10)

numeric(10)

numeric(8)

numeric(8)

numeric(8)

smallint

money

money

money

tinyint

tinyint

bit

nvarchar(25)

nvarchar(25)

nvarchar(15)

nvarchar(50)

varchar(15)

money

money

money

money

nvarchar(max)

datetime

tinyint

<pk>

<fk4>

<fk1>

<fk2>

<fk3>

<fk5>

<fk6>

<fk7>

SalesLT.Dim Product

Product Key

ProductID

Name

ProductNumber

Color

StandardCost

ListPrice

Size

Weight


SellStartDate

SellEndDate

DiscontinuedDate

ThumbNailPhoto

ThumbnailPhotoFileName

Product Model Name

CatalogDescription

meta_ValidFrom_Date

meta_ValidTo_Date

meta_Status_Flag

...

numeric(10)

int

nvarchar(50)

nvarchar(25)

nvarchar(15)

money

money

nvarchar(5)

decimal(8, 2)

numeric(10)

datetime

datetime

datetime

varbinary(max)

nvarchar(50)

nvarchar(50)

XML

datetime

datetime

tinyint

<pk>

<fk>

SalesLT.Dim_Date

DateKey

FullDateAlternateKey

DayNumberOfWeek

EnglishDayNameOfWeek

HungarianDayNameOfWeek

DayNumberOfMonth

DayNumberOfYear

WeekNumberOfYear

EnglishMonthName

HungarianMonthName

MonthNumberOfYear

CalendarQuarter

CalendarYear

CalendarSemester

FiscalQuarter

FiscalYear

FiscalSemester

meta_ValidFrom_Date

meta_ValidTo_Date

meta_Status_Flag

...

numeric(8)

date

tinyint

nvarchar(10)

nvarchar(10)

tinyint

smallint

tinyint

nvarchar(10)

nvarchar(10)

tinyint

tinyint

smallint

tinyint

tinyint

smallint

tinyint

datetime

datetime

tinyint

<pk>

<ak>

Adatminőség biztosítás egy lehetséges módja


DWHStag

e

Adattisztító alkalmazás

Adatminőségi riportok

Adatminőségi riportok- Hibás adatok kezelése- Hogyan töltsük?- Mit ne töltsünk?

- Speciális esetek pl:- Banki környezetben

kötelező jelentések

Javítások a forrásrendszerekben

Javítások a DWH-ban(adattárház hibák)

Az adattárházak komponensei: jogosultság kezelés és adatbiztonság


i) Jogosultsági szintekii) Érzékeny adatok iii) Üzemeltetés – fejlesztés – környezetek

Az adattárházak komponensei: Klasszikus adattárház és Big Data


Az adattárház projektek főbb elemei


• Üzleti követelmény felmérés• IT követelmény felmérés• Jogosultság kezelés• Tesztelés tervezés• Meta-adat tervezés• Adatmodellezés• ETL tervezés• Logikai mapping - BA• Fizikai mapping - fejlesztés• Adatbázis fizikai terv• Üzemeltetés tervezés• Tesztelés• Adatpiac tervezés (adatmodellezés, riport tervezés, logikai, fizikai map, • riport fejlesztés tesztelés)• Szervezet kiépítés• Oktatás

Tesztelés

30

RGPH/MEDI/GRIT

SAP BW

RGPL

RGRO

Anyavállalat

Árbevétel

Anyaggazdálkodás Gyártás

COPA RGRU

Árbevétel

Anyaggazdálkodás Gyártás

COPA

További leányvállalatok

ÖnköltségÁrbevétel

WEU-s adattárház

Szolgáltatások értékesítési

költség korrekciója

Anyagmozgások Zárókészletek

Konszolidált készletek

Pénzügyi adatok (pl. vám,

bérmunka)

Konszolidált önköltség

Konszolidáció (BCS)

Szolgáltatások értékesítési költség korrekciója (WEU)

Konszolidált fedezet

...

Konszolidált cikkszámok

KOFER

Önköltségi beépülési

adatok DWH alapadatok tesztje

Feldolgozások tesztje

Töltések tesztje

Outputok tesztje

Tipikus adattárház projekt szervezet


Projekt Irányító BizottságProjekt Szponzor

Kulcs Stakeholderek

PM

DW Architect/ Technikai

vezető

Üzleti elemző Team

Adat-modellező(k)

ETL Team BI TeamÜzemeltetés

Team

Üzleti elemzők/ Tesztelők

ETL Fejlesztők/ Tesztelők

BI Fejlesztők/ Tesztelők

DBA

ReleaseManager

ETL Üzemeltetés

Rendszer Admin

Agilitás az adattárház építésben


Back-end: töltési megközelítés: „vigyünk mindent”, modellezzük ami kellFront-end : klasszikus agilis módszerek: SCRUM, „prototípus”- Megfelelő BI eszközök – Klasszikus Bi eszközök vs „önkiszolgáló BI”

- „Sand-box” az éles környezetben

Mitől sikeres egy adattárház projekt


- Terjedelem : ne lőjünk nagyra de legyen hosszú távú víziónk – rugalmasság, időt-állóság a legfőbb tervezési szempont- Megfelelő szervezet / data governance- Az üzlet és az IT szoros együttműködése : „nem kínai fal”, üzleti célok vs IT költségek- Agilitás- Szponzor- Több beszállító vs. Egységes adattárház építési módszertan (monopólium vs verseny)- Ügyfél – beszállítók partnersége (Saját szervezet vs beszállítók)

- Kulcs ügyfél oldali pozíciók:- PM- Adatmodellező- „Data steward” - BI helpdesk- Üzemeltetés

- Adatminőség biztosítása- Tesztelés tervezése időben

Köszönöm a figyelmet!

34

mi a szerepe az informatikai - mmk.hu · pdf filemi a szerepe az informatikai projekt...

Documents