A NAP IDÉZETE: Nem a felhasználó dolga tudni, hogy mit is akar It s not the customer s job to know what they want. (Steve Jobs)

Átírás

1 Információmenedzsment, 2. HÉT (3. óra) IT RENDSZEREK TERVEZÉSE Dr. Danyi Pál, egyetemi docens, BME, A NAP IDÉZETE: Nem a felhasználó dolga tudni, hogy mit is akar It s not the customer s job to know what they want. (Steve Jobs) Steve Jobsnak igaza van, ha a fogyasztói informatikára gondolunk. Az iphone-t, a táblagépeket, korábban a zenelejátszókat (kezdve a 80-as évekbeli Walkman-től az ipod-ig), a személyi számítógépeket nem a felhasználók kényszerítették ki a gyártóktól. A vállalati informatikára viszont nem érvényes a fenti mondás, sőt pont az ellenkezője igaz: szinte mindig felhasználói igényre jönnek létre rendszerek. Egy vállalat sohasem engedheti meg, hogy az informatikusok saját ötletük, kényükkedvük szerint kísérletezgessenek új rendszerekkel: egy vállalatnál az információrendszerek mindig és kizárólag üzleti döntésre, vagy legalábbis üzleti jóváhagyással kerülnek kifejlesztésre. 1. Az IT menedzsment modellje IT menedzsment modellje szerint elkezdjük részletesen végigbeszélni az információrendszerek létrehozásának és működtetésének egyes lépéseit. Fontos megjegyezni, hogy amíg a Plan, Build, Run fázisok egy-egy IR-re vonatkoznak, addig a többi fázis (IT stratégia, pénzügyi tervezés, igény- és portfoliómenedzsment) mindig a teljes IT környezetre, azaz az összes IR-re együtt vonatkoznak.

2 2. IT menedzsment részletes modellje: TERVEZÉS (PLAN) A TERVEZÉS fázis lépései a következők: TERVEZÉS 0. Probléma definiálás 1. Üzleti igények (követelmények) Megvalósíthatósági elemzés (2.Erőforrás igény 3.Architektúra 4.Pénzügyi terv) 5. Funkcionális specifikáció 6. Szállítói tenderezés 7. Szerződés 2.0. A PROBLÉMA DEFINIÁLÁSA Munkatárs (felhasználó) által észlelt problémák azonosítása Vezetői megértés, támogatás Szervezeti küldetés, szervezeti célok, stratégia megértése Jelenlegi működés elemzése (számszerűsítve) Kinek fáj? Ki lesz a szponzor? Ki áll mellé? Felsővezetés vagy ágazati vezetők? Döntés: Induljon projekt! Projektterv. Mindegyik felsorolt pont eléggé magától értetődő, de a Kinek fáj magyarázatra szorul: Nem lehet sikeres egy olyan fejlesztési projekt, ami nem égető szükségből indul. Ha nem fáj eléggé a vállalatnak, vagy egy megfelelő szinten lévő vezetőnek a probléma, amire a rendszer készül, és nincs elég elkötelezettség, akkor előbb-utóbb elvágják a fejlesztés útját:, nem fognak ráérni a szükséges szakértők, hogy a tervezésben részt vegyenek, nem lesz rá pénz befejezni, vagy éppen nem fogják használni a már

3 elkészült rendszert. A legnagyobb támogatást azok a rendszerfejlesztések kapják, amelyek a legmagasabb szinten, a vállalat vezetői számára is fájó problémát terveznek kiküszöbölni. A Probléma definiálás végén kell döntenie a vállalat vezetőségének arról, hogy induljon-e projekt IR fejlesztésre az adott probléma kapcsán vagy sem. IT és az Üzlet viszonya Régebben az Üzlet (azaz egy üzleti terület, igazgatóság, pl. marketing) kiadta az igényt az IT-nak, hogy ezt meg azt kérjük. Az IT megértette, lefejlesztette, és visszaadta a kész terméket, azaz az információrendszert. Az IT-t gépház -nak is csúfolták, mert ott csupa technikai ember, informatikus dolgozott, akik az üzleti folyamatokhoz vajmi keveset értettek. Mindez igaz volt a 2000-es évek elejéig. Az elmúlt tíz évben nagy változás, hogy a két terület közel került egymáshoz. Az igényeket sem egyedül, hanem együtt fogalmazzák meg, és a rendszerek fejlesztésében is egyre komolyabban részt vesznek az üzleti területek munkatársai. Mindez annak (is) köszönhető, hogy az üzleti szakemberek is komoly oktatást kaptak informatikából az egyetemeken, tehát van rálátásuk az IT-ra, nem hottentotta az informatikusok által használt nyelv. Másrészt az informatikusok is egyre többen szereznek üzleti szakokon másoddiplomát, vagy MBA-t. Mindenesetre ez jó irány, hiszen sikeres rendszereket csak együtt fognak tudni megalkotni Üzleti igények (követelmények) meghatározása 1. Alkalmazás típus (esetleg több alkalmazás) meghatározása 2. Jelenlegi helyzet pontos elemzése 3. Üzleti célok, előnyök tisztázása 4. Érintett folyamatok, szervezeti egységek 5. Milyen folyamatlépéseket kell támogatni, és hogyan? 6. Kik fogják használni a rendszert? 7. Mikorra készüljön el a rendszer? 8. Milyen egyéb rendszerhez csatlakozzon? Pl. törzsadat-bázisok, ERP, Üzleti intelligencia, Riportoló rendszerek, Számlázó rendszer CRM példát lásd a slide-okon. Jelenleg a legfőbb vállalati alkalmazás-területek ERP (Enterprise Resource Planning) = Vállalatirányítási rendszerek BI (Business Intelligence) = üzleti intelligencia rendszerek CRM (Customer Relationship Management) Dokumentum menedzsment

4 Együttműködés, kommunikáció Web-alkalmazások, felhő-technológiák belső felhasználásra Web jelenlét: webshop, ügyfélszolgálat külső ügyfeleknek Nagyvállalati alkalmazás fejlesztés Példa: Mi egy telekom szolgáltató számára a legkritikusabb alkalmazás(ok)? A CRM alkalmazás, amelyben egyrészt rögzítik az ügyfelek által vásárolt szolgáltatásokat, termékeket, de ide rögzítik az ügyfeleknek ajánlott vagy ajánlani szándékolt termékeket is, amelyeket az ügyféltörténet elemzésével, kiértékelésével határoznak meg. Számlázó rendszer: Ebben tartják nyilván a telekommunikációs szolgáltatásokat igénybe vevő ügyfelek részletes szolgáltatás-felhasználását, ami alapján a hónap végén kiszámítják a befizetendő összeget és elkészítik a jogszabályoknak megfelelő számlát. Törzsadatbázisok: Ügyféltörzs: ami az összes ügyfél legfontosabb adatait (név, szül. idő és hely, anyja neve, lakcím, igazolvány szám, stb.) tartalmazza az egyértelmű azonosítás végett. Terméktörzs (Termék katalógus): az összes rendelhető, vásárolható szolgáltatás és termék nyilvántartása árakkal, elérhetőségekkel, amelyek száma több ezer is lehet. Pl. nem mindegy, hogy egy adott sávszélességű internet szolgáltatás elérhető-e egy adott területen, faluban, vagy sem. IR rendszerek csoportosítása kapcsolódás szerint Az IR-ek három nagy csoportját különböztethetjük meg aszerint, hogy ezek a rendszerek hogyan illeszkednek más IR-ekhez. a) funkcionális információrendszerről egy adott funkció ellátására hozzák létre, pl. marketing, számvitel, stb. támogatására b) vállalati (integrált) információrendszerről több funkcionális IR szervezeten belüli integrációja; c) szervezetközi információrendszerekről melyre az igény az e-kereskedelem megjelenésével jelent meg: két vagy több szervezet közötti információáramlást segíti elő. Jelenlegi helyzet elemzése Tevékenységek: Jelenlegi üzleti folyamatok mélyelemzése: Ki, mikor, mit és hogyan végez Meglévő rendszer fizikai elemzése Szervezeti elemzés mit változtatna meg a rendszer a szervezetben?

5 Módszerek: Megfigyelés, interjú, kérdőív, dokumentumok vizsgálata, mérések. Diagramtechnikák logikai modellek könnyebb kommunikáció -> Igények, követelmények első dokumentálása 2.2. Megvalósíthatósági elemzés Megvalósíthatósági tanulmány (Feasibility Study) Üzleti célok és követelmények egyértelműsítése Megoldási alternatívák felvázolása Maradjon a rendszer változatlan, vagy módosítsuk, korszerűsítsük, illetve fejlesszünk újat? Egyedi termék, vagy vásárolt? Ki végezze a fejlesztést? Erőforrás-igény elemzése Költség-hatékonysági elemzések -> Javaslat a munka folytatására? Üzleti célok Az IT-nek hat, egymástól jól elkülöníthető területen van hatása az új technika beépítése a meglévő rendszerekbe és szolgáltatásokba (üzleti folyamatokba), költségcsökkentés (energiamegtakarítás, jobb irányítás); döntéshozatal támogatása; vállalatközi kapcsolatok megváltoztatása; a vállalat célkitűzésének, profiljának, stratégiájának megváltoztatása; új termékek és szolgáltatások létrehozása. IT alkalmazások fejlesztésének módjai 1.Egyedi fejlesztés (home-brew/bespoke): kétféle módon: Belső fejlesztés

6 Külső fejlesztő készíti a szervezet igényeinek megfelelően 2.Dobozos (COTS, Commercial off the Shelf): Az IT alkalmazás megvásárlása (+ paraméterezés) 3.Dobozos + customizálás (személyre szabás): extrák 4.Egyéb Alkalmazás-szolgáltató (ASP): lízing Felhő alkalmazások (SaaS) Nyílt rendszerek (Open source) IT alkalmazás vásárlása (COTS) A vásárlás előnyei Nagy választék (ha commodity szoftver) Gyorsabban rendelkezésre áll a szoftver A befektetés előtt ismert a végeredmény Felhasználói tapasztalatok, amelyek beintegrálódnak az új verzióba Általában olcsóbb a fejlesztésnél Nincs akkora igény szakértőkre, mint fejlesztésnél. Kisebb kiszolgáltatottság. A vásárlás hátrányai A szoftver nem támogatja teljes mértékben az igényeket A testreszabás, módosítás általában költséges A szoftver miatt szükséges lehet a folyamatok jelentős módosítása Nincs mód a szoftverrel kapcsolatos változtatások követésére Nehézkes lehet az integráció a már meglévő informatikai infrastruktúrába A szoftvert kivonják a forgalomból, vagy a terjesztő vállalat megszűnik 2.3. IR-ek erőforrásai humán: IR-szakértők és felhasználók; hardver: fizikai eszközök rendszere; szoftver: programok, eljárások (a hardver adatok feldolgozása); adatbázisok: adatok strukturált, hatékony tárolása, menedzselése; hálózat: számítógépek közötti kapcsolatok megosztása; eljárások: munkautasítások, politikák, szabályzatok, szabványok;

7 létesítmény: irodaház (az üzleti folyamatokat végző irodák), számítóközpont, szerverszoba; 2.4. Architektúra Architektúra: a rendszer elemeinek és folyamatainak strukturális nézete, mely megmutatja az egyes részek együttműködését és kommunikációját. Az IR szerkezetének ismeretére szükség van, mert A struktúra ismeretében könnyebben érthető a rendszer működése A fejlesztési folyamat egyszerűbben szervezhető Könnyebben lehet részelemeket integrálni és eltávolítani, ha pontosan ismert a struktúra Kezelhetőbbek lesznek a komplex rendszerek. Az architektúrák összessége az architektúratérkép. VÁLLALATI Architektúra szintjei (Enterprise architecture) 1. Üzleti architektúra: szervezeti folyamatok informatikai függés 2. Rendszer (Logikai) architektúra: alkalmazások + adatkapcsolatok: a rendszer funkcionális megközelítése, mely nem foglalkozik a megvalósítás technikai részleteivel 3. Technikai (Fizikai) architektúra: a logikai architektúrát megvalósító technikai elemek rendszere (= INFRASTRUKTÚRA) 2.5. Pénzügyi terv Az új rendszer fejlesztéséről való döntést meg kell előzze a pénzügyi elemzés, aminek részeként legalább négy számítást el kell végezni a következő 6-10 éves időszakra: - Régi rendszer: Fontos megvizsgálni (és az új rendszer bekerülési költségével összehasonlítani), hogy mennyi lenne a régi rendszer fenntartási költsége. Ha nem csinálunk semmit a régi rendszerrel, annak a költsége nem nulla! Sőt, az elavult rendszerek karbantartása általában egyre drágább lesz, megszűnik a szoftverek támogatása, stb. - Új rendszer: az új rendszer bekerülési költsége, mind a fejlesztési költség (beruházási költség, CAPEX), mind a későbbi üzemeltetési, működési költség (OPEX) összege. - Megtakarítás: Az új rendszer bevezetésével mekkora megtakarítás (közvetett és közvetlen) érhető el. - Cash flow = Kumulált megtakarítás (Új rendszer kumulált költsége Régi rendszer kumulált költsége). Jellemzően néhány év kell ahhoz, hogy a cash flow pozitívvá váljon, tehát a teljes megtakarítás meghaladja az új és régi rendszer kumulált költségének különbségét.

8 ROI (Return on Investment) Megtérülés: mennyi idő alatt térül meg az új rendszerbe befektetett pénz. Itt a kumulált megtakarítást kell számítani, amikor a cash flow pozitívvá válik. Lásd az illusztrációt a slide-on. (Külön óra lesz a pénzügyi fogalmakról) 2.6. Funkcionális specifikáció A TERVEZÉS során kétszer feladat az igények és követelmények tisztázása: 1. lépés: ÜZLETI IGÉNYEK meghatározása, más néven: KÖVETELMÉNY SPECIFIKÁCIÓ. Ez egy első összegyűjtése és magas szintű leírása az üzleti igényeknek. 2. lépés: FUNKCIONÁLIS SPECIFIKÁCIÓ, más néven: LOGIKAI RENDSZERTERV. Ez már egy szinttel részletesebb funkcionális leírás: a teljesség igényével leírják, hogy milyen funkciókat kell a rendszernek majd ellátni. Jellemzően ez a dokumentum lesz a tenderkiírás szakmai melléklete. 3. lépés: Majd a FEJLESZTÉS során, a szállítókkal való szerződéskötés után készül el a TECHNIKAI, más néven: RÉSZLETES RENDSZERTERV, ami már a rendszer összes követelményére kiterjed, nem csak a funkcionálisra. Funkcionális specifikáció készítés szerepei Üzleti igények (követelmény specifikáció) megfogalmazása: az IT vevői (üzleti) oldalról az ügyvitel szervezők (más néven: folyamatszervezők) fogalmazzák meg, az IT oldalon az igénymenedzserek gyűjtik és egyeztetik első körben. Az igénymenedzserek felelnek a párhuzamosan érkező igények konszolidálásáért. Funkcionális specifikáció (logikai rendszerterv): az IT oldalon a szakrendszer elemzők, más néven: üzleti elemzők fogalmazzák meg az üzleti követelmények alapján, amit az ügyvitel szervezők jóváhagynak. Technikai (részletes) rendszerterv: rendszerszervezők (belsők vagy külsők), rendszerekhez értő IT-s (technikai) szakemberek, akik munkáját az üzleti oldalon a folyamatgazdák segítik. Funkcionális specifikáció fázisai 1. Folyamatmodellezés: adatfeldolgozási folyamatokat ábrázol 2. Adatmodellezés: adatok közötti logikai kapcsolatot definiálja 3. Funkció modellezés (Funkcionális specifikáció): a folyamat- és adatmodellezés ötvözete Funkcionális specifikáció Technológiafüggetlen

9 Meghatározza a rendszer objektumait, azok kapcsolatrendszerét Definiálja a rendszer architektúráját Modellezi a leendő rendszer működését: folyamati és adatmodell Felhasználói esetek (Use cases): milyen konkrét helyzetekben, esetekben Design tervezés nagy vonalakban 2.7. A VÁLLALAT PARTNEREI A FEJLESZTÉS SORÁN GYÁRTÓ: a szoftvert vagy információrendszert gyártó cég, pl. SAP, Oracle, Microsoft, stb. A rendszert bevezető vállalat, szervezet ritkán lép kapcsolatba közvetlenül a gyártóval, leginkább csak információszerzés ürügyén. Kisebb gyártókkal, főleg hazai gyártó cégekkel, akik közvetlenül maguk forgalmazzák termékeiket, természetesen kapcsolatba lehet kerülni, bár ők akkor már Szállító szerepkörben lépnek fel. SZÁLLÍTÓ (angolul: VENDOR): Az a cég, bizonyos értelemben viszonteladó, amelyik a gyártó cég termékeire specializálódva segít az adott (kiválasztott) terméket a megrendelő vállalnál kifejleszteni és üzembe helyezni. TANÁCSADÓ (Konzulens): Segít eligazodni a piacon. Mint független cég, segít kiválasztani a szóba jövő gyártókat és szállítókat. Sokszor segít a tenderezés előkészítésében és lefolytatásában, a szállítók kiválasztásában, a szállítói ajánlatok kiértékelésében. SZÁLLÍTÓI TENDEREZÉS Szállító kiválasztás célja: partnerséget kötni olyan beszállítókkal, akik képesek a rendszert lefejleszteni, működőképesen átadni, és mindezért megfelelő garanciát vállalni. Kiválasztási szempontok: Illeszkedés a követelményekhez, ill. a funkcionális specifikációhoz Ár ( közös nevezőre hozás : árak összehasonlíthatók legyenek) Szállító által nyújtott megoldás referenciája (Jellemzően megoldás és nem termék szállítása a cél) Szállítói tapasztalat: a cég referenciája (szakmai kvalitás bizonyítása) hasonló piacon Kulcsszakértők életrajzai (Programmenedzser, rendszer szakértők) Garanciák: Költség, Idő, Minőség 2.8. Szerződéskötés a szállítóval / Partnerekkel Fővállalkozó kérdése (EGY felelős legyen): ha nem egy fővállalkozó van, akkor a különböző résztvevők egymásra mutogathatnak nem teljesítés vagy csúszás esetén Finomított funkcionális specifikáció

10 Határidők, projektterv Leszállítandók Oktatás: a szállítónak felelőssége a leendő felhasználók beoktatása a rendszerhasználatra Garanciák, kötbér feltételek Költségek részletezése: Előleg: kap-e előleget a fejlesztő (szállító) Részteljesítés: milyen időközönként nyújthat be részteljesítésről számlát a szállító Teljesítés garancia: ha nem teljesít a szállító, akkor milyen kártérítést kell fizetnie. Licenc feltételek: szoftver licencek használati feltételei Karbantartási költségek (egyben vagy külön) beruházási (CAPEX) vagy üzemeltetési (OPEX) költségek. Sok esetben mind a megrendelő cégnek, mind a szállítónak érdeke lehet, hogy a fejlesztési költséghez csapják az első néhány évre vonatkozó karbantartási, licenchasználati költséget is, pl. akkor, ha a beruházási költség rugalmasabban növelhető.

11 Információmenedzsment, 3. HÉT (5. óra) IT RENDSZEREK FEJLESZTÉSE I. 3. IT menedzsment részletes modellje: BUILD FEJLESZTÉS 1. Részletes tervezés és rendszerterv 2. Implementáció (programozás, testreszabás) 3. Szállítómenedzsment 4. Tesztelés, minőségmenedzsment 5. Átadás üzemeltetésre Tipikus IT Fejlesztési problémák

12 3.1. RÉSZLETES TERVEZÉS (Detailed Design) Kiindulás: TERVEZÉS során: Funkcionális Specifikáció: Funkcionális követelmények magas szintű meghatározása 1.Részletes logikai (funkcionális) terv(ezés) Technológiafüggetlen funkcionális leírás A rendszer működésének folyamatlépései, szakterületi követelmények Rendszer felhasználói, szerepek 2.Design terv(ezés), Felhasználói képernyők megtervezése Ergonómia, felhasználó-barátság, egyéb nem funkcionális követelmények 3.Fizikai (Technikai) terv(ezés) Működési környezet: biztonsági szintek, felhasználási körülmények, megbízhatóság Sebesség (válaszidő) követelmények Architekturális követelmények, kapcsolódások más rendszerekhez -> Hardver- és szoftverigények, hálózati kapcsolatok, DBMS, utility programok A Részletes Tervezés szereplői Megoldás tervező (Solution designer): az alkalmazás bevezetésének szakértője, mind folyamati, mind megvalósíthatósági oldalról (pl. több sikeres SAP bevezetést csinált már) Vállalati fő architekt (főépítész, Enterprise Architect): az összes vállalati rendszer teljes összhangját biztosítja, technikai szinten is Üzleti elemzők (Business analyst) és Rendszerszervezők (System analysts, engineers): azok az üzleti alkalmazásokhoz értő IT-s (technikai) szakemberek, akik munkáját az üzleti oldalon a folyamatgazdák (Process manager) segítik. Rendszer architect/építész (System architect): a fejlesztett alkalmazás technikai megoldásait ismeri (pl. SAP szakértő)

13 3.2. Implementáció (Kivitelezési fázis) Forráskód létrehozása (programozás / coding) Rendszerkörnyezetek beállítása: Fejlesztési környezet Teszt környezet Elkészítendő dokumentációk Programtervek Tesztelési tervek Felhasználói kézikönyvek Üzemeltetési előírások Biztonsági követelmények, pl. RIBSZ (Rendszerszintű Informatikai Biztonsági Szabályzat) Válassz kettőt A Projekt sikerkritériumai: IDŐ KÖLTSÉG - MINŐSÉG A fejlesztések során jellemzően mind a három követelményt üzleti szempontok alapján üzleti vezetők hozzák meg. Emiatt történik az, hogy szinte lehetetlen mind a három követelménynek megfelelni, mert nem veszik figyelembe a technológiai korlátokat, realitásokat. Az a jó vezető, aki időnyomást alkalmaz, ami ráadásul könnyen indokolható üzleti szempontokkal, hiszen minél hamarabb elkészül a rendszer, annál hamarabb lehet hatékonyságot növelni, költséget csökkenteni, a célokat teljesíteni. Ha az időt rögzítjük, akkor vagy a költségen, vagy a minőségen kompromisszumot kell kötni. Ezért javasolt az, hogy a fejlesztésért és költségért felelős projekt vezetőt és a fejlesztési vezetőt független szervezetbe tegyük a minőségért, tesztelésért felelős vezetőtől. Ha nem függetlenek, akkor könnyen a szőnyeg alá söprik a problémákat. Ha viszont fennáll a függetlenség, akkor a kompromisszumot a közös vezetőnek kell meghozni, aki legtöbb esetben az IT igazgató. Ő pedig eldönti, hogy saját hatáskörben dönt a minőség-költség-idő dilemmában, vagy azt felterjeszti a vállalat vezetőségének. A legjobb gyakorlat az, hogy a realitásokat figyelembe véve határozzák meg a három alapkövetelményt, esetleg feszítve a költségen, vagy az időn keveset, hogy legyen egy egészséges kihívás a fejlesztő csapat előtt 3.3. Szállítómenedzsment A program- és projektmenedzser között jellemzően csak méret, azaz rendszerkomplexitás különbség van. Jellemzően nagyon nehéz jól képzett, megfelelő tapasztalattal rendelkező programmenedzsert találni a projektek élére, akik sikerrel tudják menedzselni a több milliárdos

14 projekteket. Nem csak szakmához kell érteniük, hanem az emberekhez is, és jó politikusoknak is kell lenniük a felsővezetőkkel való kapcsolattartásban, kommunikációban. Programmenedzser: 500 MFt-os projektek felett Projektmenedzser: 500 MFt projektek alatt Minőségbiztosítás (Quality Assurance): projekt követése. Lehet belső és külső. PIB (Projekt/Program Irányító Bizottság), 6-10 fő: szponzor, PM, szállító oldali PM, üzleti terület képviselője, IT fejlesztési és üzemeltetési vezetők, fő architekt, alkalmazás szakértők (külső és belső) Heti/Havi előrehaladási (progress) riportok 3.4. Tesztelés, szoftver minőségmenedzsment Unit teszt: a rendszer komponensek önálló tesztelése Rendszerteszt: a rendszer egészének tesztelése Felhasználói /Elfogadási teszt (User Acceptance Test, UAT): összes lehetséges felhasználói input tesztelése Egyéb tesztek: Volumenteszt, teljesítményteszt Stresszteszt: csúcsra járatás Teszt feladatok: Szoftverek verifikációs vizsgálata (az ELJÁRÁS ellenőrzése) Programhelyesség-vizsgálat, modulonkénti és azok együttes tesztjei Szoftverek validitási vizsgálata (a VÉGEREDMÉNY ellenőrzése) Megbízhatósági és funkcionalitási teszt, teljesítményteszt, stresszteszt

15 A Verifikáció erősíti, hogy a Validáció rendben lesz Teszt típusok: Manuális input Félig automatikus: pl. Tesztadat generátorok Automatikus tesztkörnyezetek Teszt feladatok: Részletes tesztstratégia és tesztelési terv Teszt forgatókönyvek (script-ek) előállítása Tesztek dokumentálása Hibajegyek feladása Átadás üzemeltetésre (ÉLESÍTÉS) Éles környezet kialakítása, beállítása Installálás, próbaüzem Átállási stratégiák: Big bang, vagy Párhuzamos futtatás, vagy Fázisonkénti átadás

16 Átállási (Cut-off) dátum ÉLESBE MEGYÜNK (GO LIVE) ÁTÁLLÁS: Program élesítés Adatok migrációja (ellenőrzéssel) GO/NO GO döntés: az átállási folyamat során el kell dönteni egy adott ponton, hogy átállunk-e az új rendszerre, vagy mégsem, és visszaállunk a régi rendszerre. Ennek az időzítése azért fontos, mert a Go/No Go döntés után már nincs lehetőség (elég idő), hogy mégis meggondoljuk magunkat: tehát ha Go mellett döntünk, akkor utána nem lehet mégis a régire visszaállni. Átadás utáni ellenőrzés: Kezdeti turbulenciák: help desk, lassulások, leállások, hibák. Adatmigráció Az üzembe helyezés legfontosabb lépése az adatok migrációja. Erre azért van szükség, mert a legtöbb esetben nem üres rendszerrel kezdjük az éles felhasználást, hanem már ügyfelekkel, termék-adatokkal, árakkal és egyén alapadatokkal feltöltött rendszert kezdünk használni. Felmerülő problémák: Kerekítések, levágások Más számábrázolás Beépített feltételek Elírások Más formátumok Azért is fontos az adatok tisztítása migráció előtt, és a migrált adatok ellenőrzése migráció után, mert a migráció ideális alkalom a visszaélésekre.

17 Információmenedzsment, 4. HÉT (7. óra) IT RENDSZEREK FEJLESZTÉSE II 4. Rendszerfejlesztési módszerek és modellek 4.1. A fejlesztési modellek csoportosítása Életciklus modellek Klasszikus (egyszerű) vízesésmodell Visszacsatolásos vízesésmodell V-modell Prototípus (azaz Működő) modellek Eldobható (throwaway) prototípus: így nézne ki Feltáró fejlesztési modell Tapasztalatokon alapuló fejlesztés Inkrementális fejlesztés (pl. agilis fejlesztés: scrum, kanban) Spirálmodell kockázatvezérelt modell: teljes kockázat minimalizálása 4.2. ÉLETCIKLUS MODELLEK Klasszikus vízesésmodell A legegyszerűbb vízesésmodell A fázisok megléte, a fejlesztési lépések egymásutánisága Nincs visszalépési lehetőség az előző fázisra Igen pontos elvárások ismeretében alkalmazható Nagyvonalú fejlesztési elképzelések esetén nem megoldás Ellentmond az iterativitás elvének magas kockázat Visszacsatolásos vízesésmodell Lehetőség van korábbi fázisokhoz való visszatérésre Így kezelhetőbbek a hibák Folyamatos korrekciók kisebb kitérők Lassabb

18 Csábít a felületesebb átgondolásra, pontatlanabb specifikációra A fejlesztés vízesésmodellje Rendszerfejlesztés V-modellje A V-modell lényege, hogy az életciklus modelleknél megismert fázisokat speciális sorrendben, párosával hajtjuk végre: minden fázissal egyidőben elvégezzük annak a fázisnak a verifikációs vagy validációs folyamatának a pontos megtervezését is. Vagyis pontosan fogjuk tudni, hogy egy fázis elvégzésének melyek lesznek a tesztelési lépései, hogyan fogjuk eldönteni, hogy az adott fázisban elkészült produktum megfelelő-e vagy sem. Egy V betű két szára mentén balról jobbra sorrendben felírjuk az elvégzendő feladatokat. Minden bal oldali tevékenységgel egyidőben el kell végezni a vonatkozó tesztelés megtervezését is. Például a követelmények meghatározásával egyidőben ki kell dolgoznunk azt is, hogy az elkészült termékben hogyan fogunk megbizonyosodni arról, hogy a késztermék megvalósítja-e a követelményeket. Ugyanígy, a rendszertervvel egyidőben ki kell dolgoznunk a rendszer tesztelésének a pontos lépéseit, a tartalmi lépésekkel együtt: mit, mikor, milyen sorrendben fogunk majd tesztelni. A lenti ábrákon feltüntetett munkafázisokon tehát egyszerre mindkét oldalon felülről lefelé megyünk végig.

19

20 Az életciklus modellek kritikája A vízesésmodellek egymásra épülő fázisokat rögzítenek Módosítás esetén minden ráépülő fázist újra végig kell csinálni Befejezési kritériumokat kell rögzíteni Mikor tekintünk befejezettnek egy fázist? (Határidő, pénz, ütemezés) Szabványok, dokumentációk, értékelő megbeszélések A kivitelezés fázisát hangsúlyozza Nem foglalkozik a rendszerkövetéssel, a minőségellenőrzéssel és karbantartással A korszerűbb vízesésmodellek a rendszerfelügyelet iterációját is tartalmazzák Az életciklus modellek előnyei: Világos a tevékenységek struktúrája Követhető, tervezhető a megvalósítás Pontos specifikáció esetén jól működő rendszert kapunk Az életciklus modellek hátrányai: A valós rendszerek nem követik az igények iterációját, nehéz a korrekció Nem ismerhetők pontosan az elvárások, nagy a bizonytalanság Nem biztos, hogy a rendszer ki fogja elégíteni az igényeket (rejtett hibák maradhatnak, a felhasználók aktív részvétele szükséges) 4.3. Nagyvállalati fejlesztés: 4 komplexitási szint Példa: (Webshop) fejlesztése: 1. Tartalom módosítás (CMS funkció Content Management System) 2. Paraméterezés 3. Kisebb fejlesztés 4. Nagyobb fejlesztés 4.4. Prototípus (Működő) modellek Prototípus (Működő) modell:

21 olyan tervezési koncepció, ahol a fejlesztő egy, a valós működést szimuláló, a felhasználó számára (számítógépen) bemutatható modellt, prototípust készít azzal a céllal, hogy a felhasználó véleményezze azt, döntsön arról. Indokolja: a felhasználói igények pontatlansága, a fejlesztők bizonytalansága Lehetőségek: Feltáró jellegű prototípuskészítés: a felhasználói igények pontosítására ( móricka rajz ) Tapasztalatokra (előzményekre) épített prototípus: specifikálhatók az ismert megoldáshoz képesti elvárások Prototípus modell A feltáró és a tapasztalatokon alapuló prototípusok hátrányai: A prototípus nem tartalmaz minden kritikus elemet, így kulcsfontosságú részek kimaradhatnak Nem szimulálható és nem modellezhető a rendszer elemeinek együttműködése, a megbízhatóság, biztonság, rugalmasság A prototípusváltozatok nem specifikáltak és nem dokumentáltak A tervezetlenül készített elemek redundanciát okozhatnak, nehezítve a karbantartást és a fejlesztést A prototípuskészítés előnyei: A legfontosabb funkciók gyorsan rendelkezésre állnak, megvitathatók

22 A termék fejlesztés közben is látható, könnyebben fejleszthető Kisebb az esély, hogy felesleges opció kerül a rendszerbe, ill. felesleges fejlesztés történik Életciklus modellek vs. Prototípusfejlesztés Életciklus modellt használunk általában a komplex fejlesztéseknél, amit sok száz/ezer felhasználó fog használni vagy sok száz cég megvásárolni, és ahol szigorúan meghatározott technológiai sorrendben kell az egyes szoftverelemeket egymáshoz kapcsolni. A könnyebb érthetőség kedvéért nem szoftveres példát hozva, pl. egy autó, egy mobiltelefon gyártása esetén ilyen technológiai fegyelemre van szükség. Ilyenkor nem lehet tévedni a tervezés esetén, mert akkor több ezer készüléket gyártunk le rosszul. Viszont egy Forma 1-es autó kialakítása abszolút követi a prototípus-fejlesztés menetét: mivel egyszeri termék előállításáról van szó, ezért belefér a folyamatos kísérletezés Inkrementális fejlesztés Az életciklus és prototípus modellek előnyeinek ötvözése: kisebb, kezelhető funkcionális egységekre bontás. Az inkrementális fejlesztés lényege, hogy kisebb egységekben, ún. inkrementumokban történik a fejlesztés. A teljes fejlesztés projektjét valamilyen életciklus modell szerint tervezik, de azon belül az egyes fázisok, inkrementumok tervezése és fejlesztése elsősorban gyors fejlesztéssel, pl. prototípus-

23 alapú fejlesztéssel történik. Az autós példánál maradva, az alváz, a motor, a karosszéria kifejlesztése történhet külön-külön prototípus modell szerint, majd ezek egymásra építése történik. A módszer legnagyobb kockázata és hátránya az, hogy az egyes inkrementumokat esetleg nehéz illeszteni az eddig elkészültekhez AGILIS termékfejlesztés (SCRUM) Az elmúlt évek legnépszerűbb szoftverfejlesztési módszertana az agilis fejlesztés, azon belül is a SCRUM-nak nevezett módszertan. A SCRUM egy inkrementális típusú fejlesztés, ahol az inkrementumok ún. Sprintekben (futamokban) készülnek. Kétféle ciklus van: a sprintek általában havi, vagy annál rövidebb (akár hetes, kéthetes) munkák elvégzését jelentik, de napi iteráció is van: a naponkénti SCRUM találkozók, ill. megbeszélések szigorúan ellenőrzik az előrehaladást és annak alapján módosítanak az elvégzendő munkákon. A feladatlista elnevezése backlog. Csapat (Scrum Team) főből áll. A csapattagok különféle képességei lehetővé teszik, hogy a feladatot közösen megoldják (fejlesztő, dizájner, tesztelő,...) Scrum Master - elhárítja az akadályokat, amelyek gátolják a csapatot abban, hogy a futam célját megvalósítsa. Nem szó szerint projektvezető, de ő az, aki jól ismeri a módszertant és egyben tartja a fejlesztést.

24 4.6. Spirálmodell A spriállmodell olyan kockázatvezérelt rendszerfejlesztési megközelítés, ami állandóan a projekt teljes kockázatát próbálja minimalizálni. Olyan fejlesztést jelent, ahol az elemzés-tervezésmegvalósítás-értékelés gyors ciklusokban megy végbe, és a következő fázis előrehaladási irányát, feladatlistáját kockázatelemzéssel döntik el.

25 MVP (Minimálisan életképes termék) A spriálmodell egyik jól ismert megvalósulása az MVP (Minimum Viable Product, magyarul minimálisan életképes termék) módszertan, amit Eric Ries fogalmazott meg a Lean Startup c. könyvében. Az elsősorban startup vállalkozások számára javasolt megközelítés szerint nem érdemes azonnal egy teljesen jól funkcionáló, hibátlan terméket drágán elkészíteni, hanem egy olyan gyorsan, olcsón összerakható prototípussal kell kezdeni, ami alapján a potenciális felhasználók megértik a koncepciót, amit tudnak tesztelni, véleményt mondani róla. Íly módon minimalizálni lehet a fejlesztés kockázatát: csak annyit csináljunk meg egyszerre, ami nem jelent túl nagy felesleges munkát rossz visszajelzés esetén. Ahhoz, hogy kiderüljön, mit kell másképp csinálnunk, miben kell a terméket módosítanunk, mérni kell a visszajelzéseket, az adatokat gondosan fel kell dolgozni, annak alapján pedig újra lehet specifikálni a prototípus vagy termék következő verzióját. Az MVP elvű termékfejlesztés ciklusa:

26 Forrás: Eris Ries: Lean startup, HVG 2013