5.1. A sorokban álló állítások az oszlopokkal adott kategóriák melyikére jellemzıek? 1. Célja a szervezetnél lévı szoftverek által nyújtott szolgáltatások áttekinthetıségének, mérhetıségének és összhangjának javítása. 2. Megmutatja, milyen függések vannak a szervezet szoftverei között (pl. használja a másikat, vagy együtt tud mőködni a másikkal, vagy kizárja a másikat). 3. A szoftvervagyont érintı bármilyen döntés megalapozását szolgálhatja. 4. Beletartoznak az egy-egy adott szoftver beszerzésével vagy fejlesztésével kapcsolatos irányítási és végrehajtási funkciók. 5. A szoftverek között duplikációk, átfedések, illeszkedési problémák feltárása. 6. A szoftverek között feltárt duplikációk, átfedések, egymáshoz és a vállalati szabványokhoz nem illeszkedı megoldások megszüntetése. 7. A szoftverekkel kapcsolatos fejlesztési, mőködési és karbantartási költségek csökkentése szervezeti szintő szabványosítás, integráció révén. 8. Választ tud adni arra a kérdésre, hogy milyen alkalmazások vannak a szervezetnél. 9. Az eredményesség javítása az üzleti szükségletekhez jobban illeszkedı szolgáltatások kialakítását célzó fejlesztési projektek révén. 10. Megmutatja, hogy a szervezet szoftverei milyen mőszaki és architekturális környezethez hardverhez, operációs rendszerhez, adatbáziskezelıhöz, programozási környezethez kötıdnek. Szoftvermenedzsment Alkalmazásportfólió menedzsment Nyilvántartás Elemzés Konszolidáció Racionalizálás
140 Gazdasági informatika 5.2. Határozza meg, hogy a szoftver életciklusfolyamatok szabványa szerint az alábbi sorokban álló állítások az oszlopokban álló mely életciklusfolyamatokra igazak! Beszerzési folyamat Dokumentálási folyamat Erıforrásbiztosítási foly. Karbantartási folyamat Fejlesztési folyamat Igazolási folyamat Érvényesítési folyamat 1. A támogatási folyamatok közé tartozik. 2. A termék szerzıdéses követelményeknek megfelelıségét bizonyítja. 3. A szervezeti folyamatok közé tartozik. 4. A mőszaki nézetbe tartozik. 5. A termék terveknek, azaz más termékeknek megfelelıségét bizonyítja. 6. A szerzıdéses nézetbe tartozik. 5.3. Határozza meg, hogy az alábbi sorokban adott tevékenységek a projektfolyamat melyik vetületébe tartoznak! A projekt célja az önkormányzat építéshatósági szakigazgatási eljárásait támogató szoftver kifejlesztése Fejlesztési folyamat 1. Gondoskodás arról, hogy adott fejlesztési tevékenységhez a végrehajtó projekttagok a terv szerint rendelkezésre álljanak. 2. A tesztspecifikációk sablonjának kialakítása, és ehhez a kitöltési utasítás elkészítése. 3. A tesztspecifikációk megírása a részletes funkcióspecifikációk alapján. 4. Annak ellenırzése, hogy a tesztelést a tesztspecifikációk szerint hajtották végre. 5. A tesztelés során feltárt hibák javítása. A fejlesztendı terméket érintı jogszabályok és szabványok 6. tanulmányozása. 7. A projekt végrehajtása alatt elkészült tervek, termékek verzióinak nyilvántartása Támogatási folyamatok Szervezeti folyamatok 8. Új technológiát ismertetı tanfolyam megszervezése.
A szoftver életciklusa 141 5.4. Egy városi közlekedési forgalmat figyelı és a forgalomirányítást támogató információs rendszerre vonatkozó interjúk a következı követelményeket tárták fel: A rendszernek adatokat kell szolgáltatni A személygépjármővek, motorkerékpárok, kerékpárok és tömegközlekedési eszközök áramlására vonatkozóan évszakokra, napokra, speciálisan munkanapokra és munkaszüneti napokra, valamint napon belüli idıszakokra bontva; a tömegközlekedésben résztvevık számáról; a város és a városon kívülrıl érkezık áramlásáról régió szerinti felbontásban (adott területekrıl merre mennyi ember mozog); a közlekedéssel eltöltött idırıl (a közlekedık számával súlyozott átlagban); útvonalhálózatról, és az utak, útvonalszakaszok áteresztıképességérıl. A rendszernek operatívan támogatást kell nyújtani a térfigyelı kamerák és forgalomszámláló berendezések adatainak győjtéséhez és kiértékeléséhez; a közlekedést irányító lámpáknak a forgalom intenzitásához igazodó, optimális vezérlésének beállításához; váratlan rendkívüli helyzetek (közúti baleset, üzemképtelenné vált gépjármő, közmő meghibásodás, közmőjavítási munkálatok által okozott akadály) kezelésére; elıre ismert (bejelentett) rendkívüli helyzetek (közutat érintı tömegrendezvények, különleges jármőszerelvény áthaladása, jármő-menetoszlop áthaladása, javításifelújítási munkálatok) kezelése; a tömegközlekedés napi szinten, valamint napon belüli idıszakok szintjén hatékony (a forgalom intenzitásához, a tömegközlekedési eszközökre várakozók számához dinamikusan igazodó, kielégítı, de a költségeket minimalizáló) kiszolgálásához. A rendszernek támogatást kell nyújtani a városi közlekedés alakítására vonatkozó elemzések, különbözı távú tervek készítéséhez, taktikai és stratégiai döntések meghozatalának támogatásához. Ilyen támogatandó feladatok: További térfigyelı kamerák és forgalomszámláló berendezések beszerzésének és elhelyezésének tervezése. Utak, útszakaszok felújításának és a közmővek felújításának összehangolt tervezése. A felújítási munkák ütemezésének optimalizálása. A rendkívüli esetek gyakoriságának, területi eloszlásának elemzése a megelızés és az ilyen esetek kezelésére való jobb felkészülés céljából. Forgalomterelési módszerek lefektetése. A tömegközlekedés szükséges átszervezését feltáró elemzések végrehajtása. Pl. egyes járatok útvonalának módosítása, új járatok indítása, dinamikus járatok létrehozása (taxi jelleggel közlekedı buszjáratok, mint pl. az iskolabusz). A nagy utasforgalmat generáló cégekkel és cégcsoportokkal összehangolt közlekedéstervezés: így a munkába járást könnyítı utak, útszakaszok kialakítása, tehermentesítése, a tömegközlekedésnek (az indított járatoknak) a munkaidıhöz igazított tervezése. Agglomerációs tervek kialakítása és ezek összehangolása a városon kívülrıl érkezı nagy forgalmat generáló transzferek kezelését célzó tervekkel. Az interjúk választ adtak még a következı kérdésekre is, amelyeket a válaszok részletezése nélkül sorolunk fel. az egyes adatcsoportoknak mely szervezetek az adatgazdái;
142 Gazdasági informatika mely szervezetek illetve munkakörök lesznek a rendszer felhasználói; a rendszer szolgáltatásai kiknek milyen formában álljanak rendelkezésre; kik (milyen beosztás, munkakör betöltıi) a kritikus helyzetek kezelésének felelısei; milyen szabályok és szervezeti keretek között történjen az üzemeltetés. Az elmondottak alapján határozza meg, mirıl fog szólni a rendszer fogalmi (szakterületi) tervén belül az adattervezési fejezet, a feldolgozástervezési fejezet és a rendszer környezetérıl (kezelendı események, érintett környezet, felhasználói felület) szóló fejezet? Az adattervezési fejezetben különítse el az OLTP adatbázisra, illetve az OLAP funkciókat kiszolgáló adattárházra vonatkozó témákat. Hasonlóan a feldolgozástervezési fejezetben különítse el az operatív mőködés támogatását az elemzési feladatok, valamint a funkcionális és stratégiai irányítás támogatásától! Az elmondottakból milyen közlések vonatkoznak az orgverre? Esetleges további interjúkkal milyen kérdéseket kellene tisztázni annak érdekében, hogy a fejlesztık támpontokat kapjanak a logikai és a fizikai szintő tervek elkészítéséhez is? 5.5. Mit értenek rendszerszervezési változatok alatt? Egy projekten belül milyen okból adódik általában több rendszerszervezési változat? Legkésıbb meddig kell választani a rendszerszervezési változatok közül? A követelmények olyan részhalmazait, amelyek egymással konzisztens és együttesen megvalósítható követelmények tartalmaznak. Az összegyőjtött követelmények együttvéve ellentmondásosak, illetve nem férnek bele az idı, pénz és erıforrások által korlátozott projektbe. A tervezés megkezdése elıtt ( dobozos termékek esetében kivételesen elıfordulhat, hogy a telepítéskor). 5.6. Milyen összefüggést lát a rendszerelmélet fekete doboz módszere és a szoftvertervezésen belüli feldolgozástervezés között? 5.7. Milyen hasznos következményei vannak a fekete doboz módszer szoftvertervezésben való alkalmazásának?
A szoftver életciklusa 143 5.8. Határozza meg hogy a sorokban adott állítások a szoftverfejlesztésnek az oszlopokban adott fejlesztési szakaszai (tevékenységei) melyikét jellemzik! Elemzés Tervezés Kivitelezés (szőkebben vett) Integráció, integrációs teszt Minıségi teszt Szoftver bevezetése 1. Ennek során történik meg az adatmigráció. 2. Célja a szoftver validációja, lehetıleg az alkalmazási környezetben. 3. Egyik terméke az architektúramodell. 4. A különbözı fejlesztık, fejlesztı teamek által létrehozott egységekbıl, alacsonyabb szintő komponensekbıl, inkrementumokból összeállítják a magasabb szintő kompozíciókat. 5. Termékei a rendszerszervezési változatok. 6. Egyik módszere: interjúk készítése a felhasználói oldal képviselıivel. 7. Elvégzik a szoftver forráskódjának megírását (röviden kódolását) és a szoftveregységek tesztelését. 8. Egyik feladata a próbaüzemi teszt. K 9. Egyik változata a próbaüzemi teszt. 10. Szoftver beszerzése (nem fejlesztése) esetén csak ezek a tevékenységek merülnek fel. 11. Az adott kompozíció közvetlen komponensei együttmőködésének helyességére koncentrál. 12. Termékei közé tartoznak a funkcionális modulok közötti interfészek specifikációi. 13. Az interfésztervek alapján készült tesztspecifikációk szerint végzik. 5.9. Mi a különbség vagy a kapcsolat az architekturális tervezés és a nagyvonalú terméktervezés között? Az elıbbi: nem-funkcionális követelményeket teljesítı megoldások elkülönítését szolgáló nagyvonalú szerkezet és sémák Az utóbbi: a szoftver funkcionális modulokra felbontása. Mindkettı: nagyvonalú tervezés (az elıbbi részletes megoldási sémáit nem számítva). nagyvonalú terméktervezés, a terméktervezés és a részletes szoftvertervezés között? a részletes szoftverterv és a megoldásmodell között? A nagyvonalú terméktervezés és a részletes szoftvertervezés összetevıi a terméktervezésnek. A nagyvonalú terméktervezés a szoftver funkcionális modulokra bontásával és a modulok közötti együttmőködéssel foglalkozik. A részletes szoftvertervezés: a modulok belsı szerkezetével, mőködési mechanizmusával foglalkozik. Az elıbbi: csak az alkalmazási szintre vonatkozó döntéseket tartalmaz. Az utóbbi: a terméktervnek az architektúramodell által kidolgozott struktúrát és mintákat maradéktalanul érvényesítı vmítva).
144 Gazdasági informatika 5.10. Pótolja az alábbi ábrán a szintek és a rétegek neveit a SunTone módszertan rendszerarchitektúra sémája szerint! 5.11. A sorokban olvasható állítások a szoftverüzemeltetési, szolgáltatás-támogatási folyamat mely alfolyamataira jellemzıek. Az ITIL szerinti alfolyamatok az oszlopokban adottak. 1. A javított, módosított és engedélyezett szoftverváltozatot összeállítja és teríti a felhasználó környezetben. 2. Amennyiben a bejelentett hiba, akadály oka ismert, ez az alfolyamat végzi annak gyors elhárítását, vagy javaslatot ad az akadály megkerülésére. 3. Ezt az alfolyamatot egy javítási igény indítja el. 4. A többi alfolyamat számára konzisztens központi nyilvántartást biztosít. 5. Kideríti a bejelentett hiba, akadály okát. 6. Erre az alfolyamatra akkor is szükség van, ha a hiba nem a szoftverben, hanem a felhasználói környezetben fennálló akadály, ami csak ezen alfolyamat segítségével hárítható el. Incidenskezelés Problémakezelés Változáskezelés Kiadáskezelés Konfigurációkezelés
5.12. Szolgáltatási szint menedzsment A szoftver életciklusa 145 Az ITIL szerint mi képezi az alábbi feladatok tartalmát? Az informatikai szolgáltatás kielégítı szintjének biztosítása, minıségének folyamatos javítása. Kapacitásmenedzsment Rendelkezésreállás menedzsment Informatikai szolgáltatás folytonosságának irányítása Informatikai szolgáltatás pénzügyi irányítása Gondoskodás a szükséges erıforráskapacitás rendelkezésre állásáról és a meglevı erıforrások minél jobb kihasználásáról. A szolgáltatásokra, infrastruktúrára vonatkozó olyan rendelkezésreállási célok elérését segíti, amely költséghatékony és támogatja az üzleti célok elérését. Támogatja az üzletmenet-folytonosságot az informatikai szolgáltatás és infrastruktúra üzleti igényeknek megfelelı, elfogadott idın belül történı helyreállításával. A költségek feltérképezése, gondoskodás a szolgáltatások gazdaságos mőködtetésérıl. Az ITIL-ben milyen feladatcsoport összetevıi a fentebb felsorolt feladatok? Szolgáltatás biztosítása feladatcsoport 5.13. elınyei? Mik a komponens alapú fejlesztés életciklusmodell szerinti fejlesztés lemezhetısége, tesztelhetısége, változtathatósága, stabilitása is. hátrányai? em alkalmazhat ha a követelmények módosításához a felhasználó (az ügyfé 5.14. a menedzserek nézıpontját? a fejlesztık nézıpontját? A RUP életciklusmodell milyen elemeiben veszi figyelembe a projekt érettségi fázisai fogalmak és az ezekhez tartozó mé az objektumorientált technológiát (megközelítési módot) támogatja; meghatározza az iterációkon belül végrehajtandó fejlesztı és támo
146 5.15. Gazdasági informatika A megfelelı oszlopokba tett -szel jelezze, hogy az alábbi sorokban álló állítások mely melyik életciklusmodellekre igazak! (Lehetnek olyan állítások, amelyek többféle modellre is igazak a felsoroltak közül.) 1. Rövidebb idın belül állnak elı mőködı részek, így mindenképpen csökkenek a hosszú átfutási idıbıl eredı kockázatok, de a teljes rendszer lassan készül el. 2. A párhuzamos tevékenységek irányítása nehéz feladat. A már mőködı részeket és a késıbbi lépések eredményeit újra és újra integrálni kell. 3. Erıskező projektvezetés hiányában a felhasználói igények parttalan szaporodásához vezethet. 4. Gyorsan elkészülnek az ember-gép kommunikációval kapcsolatos funkciók, viszont nem derül fény azokra a belsı kapcsolatokra, amelyek nincsenek közvetlen összefüggésben a felhasználói felületen megjelenı tartalommal. 5. Nagyon hosszú idı telik el a kivitelezés megkezdéséig. 6. A projekt egyszerően ütemezhetı, irányítható. Csak a szakaszok végén van visszacsatolás. 7. Az egyes iterációk menedzselése egyszerő, mert az egyes iterációk termékei jól definiálhatók, az elkülönített iterációk jól tervezhetık, kivitelezhetık, ellenırizhetık. 8. Világos képet ad arról, hogy adott tevékenység és annak terméke mely korábbi tevékenység termékének kell megfeleljen. Ezt a modellt követı projekt is egyszerően ütemezhetı, irányítható. 9. Feltételezi, hogy a követelmények pontosan ismertek és nem változnak. 10. A modell szerint a terveket tesztelı prototípus is készül. Vízesés modell V modell Evolúciós fejlesztés Inkrementális modell (Boehm féle) spirálm. RUP modell K
A szoftver életciklusa 147 5.16. A komponens alapú fejlesztés életciklusmodell következı folyamatábrájának megfelelı dobozaiban helyezze el az alábbi tevékenységeket! Tervezés Validálás Komponensek adaptálása Komponensek alkalmassági értékelése Komponensek elemzése Követelmények meghatározása Követelmények módosítása Kivitelezés, komponensek integrálása fehér doboz szürke doboz fekete doboz
148 Gazdasági informatika 5.17. Határozza meg, hogy a sorokban adott állítások az oszlopokban adott mely jelzıkre igazak! moduláris strukturált folyamatvezérelt eseményvezérelt adatvezérelt felhasználóvezérelt objektumorientált 1. Módszertancsoport jelzıje. K 2. Megközelítési mód jelzıje. 3. Ez a megközelítési mód felismerte, hogy a komplex rendszerek tervezését, fejlesztését megkönnyíti, ha K K azokat viszonylag független, önállóan megérthetı, fejleszthetı, tesztelhetı modulokra bontjuk. 4. Ez a megközelítési mód megalkotta szerkezet és a viselkedés ilyen egységét, amely a lehetséges legkevesebbet feltételezi a környezetérıl. 5. Az ilyen módszertanok kialakulása együtt járt a tranzakció-orientált feldolgozások iránti igény megjelenésével. 6. Az ilyen módszertanok a kifejlesztendı rendszert egyoldalúan a feldolgozási célok szerint tagolták. 7. Az ilyen módszertanok megjelenése az adatbázisok használatának elterjedéséhez köthetı. 8. Az ilyen módszertanban önálló és domináns vetületként jelenik meg az adatstruktúrák tervezése (az adatmodellezés). 9. Az ilyen megközelítési módban önálló és domináns vetületként jelenik meg az adatstruktúrák tervezése (az adatmodellezés). 10. Az ilyen módszertanok szoros kapcsolatban állnak a prototípuson alapuló életciklusmodellel, illetve az evolúciós fejlesztéssel. 11. Ez a megközelítési mód a fokozatos lebontás (hierarchikus lebontás / fokozatos finomítás) módszerét követi. 12. A jelzıvel minısített kategória meghatározza a figyelembe vett célkitőzések és feltételek mellett K legjobb gyakorlatnak számító termék-, folyamat- és szervezeti sémákat. 13. A jelzıvel minısített kategória sajátos absztrakciós szemléletet, fogalomrendszert, eszköztárat, elemzési (felbontási) és konstrukciós elveket határoz meg.
A szoftver életciklusa 149 5.18. -elje be, hogy a sorokban álló tényekbıl közvetlenül a szoftver mely minıségi jellemzıjére lehet következtetni! (Lehetnek több minıségi tényezıvel összefüggı tények is.) A minıségi jellemzık az MSZ ISO/IEC 9126 szabvány szerint értelmezendık. 1. A szoftver tervdokumentációja jól tagolt. Egyértelmővé teszi, hogy melyik döntés (tervelem) milyen követelmény teljesítése érdekében vagy milyen korlát figyelembe vétele okán született. 2. A szoftver fel van készítve a szabálytalan felhasználói akciók, hibás bemeneti adatok visszautasítására. 3. A szoftver eleget tesz a támogatott szakterületre vonatkozó szabványoknak, szabályoknak, törvényi elıírásoknak. 4. A szoftver nem használja ki valamely adatbáziskezelı különleges adottságait, lehetıségeit. 5. Az új szoftver felhasználói felülete nagymértékben hasonlít az alkalmazottak által eddig megszokotthoz. 6. A szoftver lényegesen különbözı teljesítményő erıforrásokon is mőködıképes, a szoftver által felhasznált erıforrások mennyisége, teljesítménye rugalmasan a terheléshez igazítható. 7. A szoftver megakadályozza a funkcióihoz és az adatokhoz való jogosulatlan hozzáférést, nyilvántartja a felhasználói tevékenységeket. 8. Az egyes funkciók interfészei jól definiáltak, ezért a szoftver egyszerően tesztelhetı. 9. A szoftver a saját eszközeinek felhasználásával könnyen igazítható különbözı alkalmazási környezetekhez. 10. A szoftver lehetıvé teszi, hogy bizonyos szolgáltatásait más alkalmazások is elérjék (használják). 11. A szoftver az iparági szinten legáltalánosabban elfogadott technológiai szabványokat követi. Funkcionalitás Megbízhatóság K Használhatóság Hatékonyság Karbantarthatóság Hordozhatóság K
150 Gazdasági informatika