UNIVERZITET U BEOGRADU FAKULTET ORGANIZACIONIH NAUKA Radovan M. Cvetković PRISTUP IZGRADNJI INFORMACIONOG SISTEMA TELEKOMUNIKACIONE KOMPANIJE ZASNOVAN NA MODELIMA doktorska disertacija Beograd, 2012 UNIVERSITY OF BELGRADE FACULTY OF ORGANISATIONAL SCIENCES Radovan M. Cvetković AN APPROACH TO BUILD INFORMATION SYSTEM OF TELECOMMUNICATION COMPANY BASED ON MODELS Doctoral Dissertation Belgrade, 2012 Mentor: dr Zoran Marjanović, redovni profesor Univerzitet u Beogradu Fakultet organizacionih nauka, Beograd Članovi komisije: dr Siniša Nešković, docent Univerzitet u Beogradu Fakultet organizacionih nauka, Beograd dr Miroslav Dukić, redovni profesor Univerzitet u Beogradu Elektrotehnički fakultet, Beograd Datum odbrane: ____________________________ Ovaj rad posvećujem svojoj porodici i prezimenu koje nosim, sada Cvetković - pre toga Radovanović Zahvalnice Ovim putem želim da izrazim veliku zahvalnost mentoru profesoru dr Zoranu Marjanoviću na svesrdnoj podršci i strpljenju, na korisnim primedbama i sugestijama tokom izrade ove doktorske disertacije. Želim da se zahvalim profesoru dr Miroslavu Dukiću, sa Elektrotehničkog fakulteta u Beogradu koji je pružao veliku podršku mom radu na razvoju IT oblasti u kompaniji Telekom Srbija i afirmisanju Telekomunikacionog Informacionog Sistema – TIS. Izuzetnu i neizmernu zahvalnost dugujem profesoru dr Siniši Neškoviću sa kojim sam proveo godine radeći na stručnim i naučno istraživačkim projektima u oblasti razvoja informacionih sistema. Ova doktorska disertacija predstavlja samo jedan deo rezultata višegodišnjeg zajedničkog rada. Zahvaljujem se svim ostalim profesorima i zaposlenima u okviru Laboratorije za informacione sisteme „Prof. dr Branislav Lazarević“, za pruženu podršku tokom izrade disertacije. Zahvaljujem se profesoru dr Slobodanu Krčevincu na korisnim sugestijama. Zahvaljujem se prijateljima, kolegama sa posla za pruženu podršku a naročito Rodoljubu Jovanoviću sa kojim sam proveo sate i sate raspravljajući o razvoju informacionih sistema. Posebnu zahvalnost dugujem profesoru dr Branislavu Lazareviću, kod koga sam diplomirao, magistrirao, započeo ovu doktorsku disertaciju, sa kojim sam radio na raznim projektima, od koga sam naučio zanat zvani „Razvoj informacionih sistema“ i koji je u velikoj meri uticao na moju stručnu karijeru. Radovan Cvetković Beograd, septembar 2012. godine PRISTUP IZGRADNJI INFORMACIONOG SISTEMA TELEKOMUNIKACIONE KOMPANIJE ZASNOVAN NA MODELIMA REZIME: U ovom radu se definiše metodološki pristup za izgradnju informacionog sistema telekomunikacione kompanije zasnovan na modelima objedinjavanjem opštih pristupa razvoja IS i specifične inicijative u oblasti telekomunikacija:  MDA (Model Driven Architecture), pristup razvoju softvera koji je kao standard utvrdila i promoviše OMG (Object Management Group).  EA (Enterprise Architecture), pristup za razvoj arhitekture preduzeća, razvoj poslovanja i IT-a istovremeno. TOGAF (The Open Group Architectural Framework) je opšti najpoznatiji arhitekturalni okvir i metod za razvoj arhitekture preduzeća.  NGOSS (The New Generation Operations Systems and Software) program koji razvija Telemanagement Forum i koji predstavlja okvir za razvoj i primenu „Operation and Business Support Systems – OSS/BSS“ u telekomunikacionoj industriji.  SPL (Software Product Line), razvoj IS preko Softverskih proizvodnih linija, predstavlja savremeni pristup za automatizaciju razvoja softvera koji je zasnovan na domenskim, specifičnim modelima gde se kroz domensko inženjerstvo razvija familija softverskih proizvoda a ne pojedinačni softverski proizvod. Osnovu metodološkog pristupa čini specifična softverska proizvodna linija za telekomunikacioni domen koja je zasnovana na NGOSS okvirima i modelima i omogućava efikasnu izgradnju IS telekomunikacione kompanije kroz tri posebna procesa:  Opšti domenski inženjering telekomunikacionog domena,  Domenski inženjering telekomunikacionog domena za tip servisa,  Aplikacioni inženjering. Da bi se definisao Metodološki okvir za razvoj IS telekom operatora zasnovan na modelima neophodno je dobro sagledavanje sledećih dimenzija složenosti telekomunikacionog domena: Funkcionalni domeni, Oblasti integrisanih procesa, Tipovi telekomunikacionih servisa, Faze životnog ciklusa razvoja IS, Konkretni telekom operatori za koje se razvija IS. Zatim je neophodno definisati međusobni odnos i definisati redosled kretanja kroz dimenzije. Na osnovu NGOSS okvira: eTOM i SID definisana je osnovna početna šema koja daje klasifikaciju telekomunikacionog domena na poddomene i horizontalne i vertikalne zavisnosti između poddomena. Kao tehnika za savlađivanje složenosti telekomunikacionog domena i prelazak sa jednog poddomena na drugi definisan je osnovni mehanizam „Višenivovsko fazno konfigurisanje“. Kada se takav mehanizam primeni na osnovnu polaznu klasifikacionu šemu dobija se sistem za višenivovsko fazno konfigurisanje telekomunikacionog domena. Posle toga je moguće definisati okvir softverske proizvodne linije za telekomunikacioni domen koji obuhvata sve prethodno pomenute dimenzije složenosti domena, kroz domenski i aplikacioni inženjering. Domenski inženjering u ovom pristupu je specifičan zbog višedimenzionalne složenosti telekomunikacionog domena i sastoji se iz dva nivoa: Opšti domenski inženjering telekomunikacionog domena i Domenski inženjering za tip servisa. Opšti domenski inženjering telekomunikacionog domena. Jedan od bitnih koraka ovog domenskog procesa je Definisanje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK). HVFK sistem ima zadatak da kontrolisano i sveobuhvatno definiše sve početne Modele karakteristika po funkcionalnim oblastima telekomunikacionog domena. Sistem se realizuje pomoću četiri HVFK šeme. Unutar funkcionalne oblasti modeli su horizontalno zavisni jedan od drugog i konstruišu se u skladu sa definisanim zavisnostima između poddomena. Pored modela karakteristika po funkcionalnim oblastima definišu se i svi neophodni UML šabloni modela: Šabloni modela podataka, Šabloni ponašanja (aplikacije i procesi), itd. Drugi važan korak opšteg domenskog inženjeringa za telekomunikacioni domen je definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK). Ovaj sistem se realizuje kroz šest konfiguracionih šema. Glavni rezultat izvršenja vertikalne višenivovske fazne konfiguracije je realizacija razvoja vertikalnih procesa kroz višenivovsku faznu transformaciju Modela karakteristika gde rezultat (konfiguracija) sa prethodnog nivoa predstavlja ulazne parametre za izradu modela na nižem nivou. Sledeći važan korak je Definisanje sistema za Generisanje Modela. Modeli karakteristika lepo predstavljaju zajedničke i različite karakteristike familije pro izvoda. Međutim modeli karakteristika nisu sami sebi svrha. Oni predstavljaju vodilju za izradu modela koji specificiraju podatke ili ponašanje nekog domena. To znači da modeli karakteristika treba da se preslikavaju u druge modele i da na njih prenesu potrebnu semantiku. Preslikavanje MK u druge modele se radi preko šeme za generisanje modela. Domenski inženjering telekomunikacionog domena za tip servisa. U ovom delu SPL za telekomunikacioni domen razrađuju se dalje konfiguracione šeme sistema za horizontalno višenivovsko fazno konfigurisanje (HVFK) koje su definisane u opštem domenskom inženjeringu. Ove šeme inače predstavljaju pravila i putanju za definisanje modela za tip servisa. Koristeći ove šeme definišu svi početni Modele karakteristika po funkcionalnim oblastima telekomunikacionog domena za IPTV servis. U drugom delu razrađuju se dalje šeme koje su definisane u opštem domenskom inženjeringu za telekomunikacioni domen i koje čine Sistem za vertikalno višenivovsko fazno konfigurisanje (VVFK). Ove šeme inače predstavljaju pravila i putanju za definisanje procesa Sa-kraja-na-Kraj za tip servisa. Koristeći ove šeme anotiraju se međusobno Modeli karakteristika i definiše postupak razvoja vertikalnih procesa za IPTV servis. U drugom delu ovog domenskog procesa definišu se i šeme za automatsko konfigurisanje i generisanje UML modela dijagrama klasa i dijagrama aktivnosti za IPTV servis na osnovu UML šablona modela za IPTV i konfiguracija modela karakteristika. Aplikacioni inženjering telekomunikacionog domena omogućava specifikaciju i generisanje IS konkretnog operatora. Istovremeno se ovaj deo a i ceo metodološki pristup ilustruje kroz postepeno krojenje i generisanje konkretnog IS za konkretnog operatora IPTV servisa. Prvo se vrši konfigurisanje zahteva IS konkretnog Telekom operatora (Obuhvat IS). Zatim se IS detaljno kroji primenom vertikalnog višenivovskog faznog konfigurisanja. Tokom ovog procesa vrši se generisanje modela IS konkretnog Telekom operatora. Metodološki pristup razvoja IS telekomunikacione kompanije zasnovan na modelima doprinosi rešavanju sledećih problema razvoja IS:  Rešavanje problema Poravnanje biznisa i IT-a (IT and Business Alignment) koje nastaje zbog razlike u nivoima apstrakcija Biznis i IT koncepata.  Nalaženje načina savladavanja Višedimenzionalne složenosti telekomunikacionog domena.  Rešavanje problema razvoja IS zbog Dinamizma poslovanja jer pored toga što je složeno, poslovanje je i vrlo dinamično zbog stalnih i brzih promena tehnologija, zahteva korisnika za novim servisima, konkurencije na tržištu, itd.  Omogućavanje Masovne kastomizacija servisa koje nisu rešili postojeći metodološki pristupi jer nisu u potpunosti rešili problem ponovnog korišćenja softvera (reuse).  Dopuna opštih EA pristupa i NGOSS domenskog EA sa detaljnim modelima telekomunikacionog domena korišćenjem postojećih IS koji funkcionišu kod konkretnih telekom operatora.  Omogućavanje efikasnije transformacije modela koja predstavlja jedan od osnovnih opštih problema u MDA pristupu. U ovom radu se na kraju daje prikaz i uporedni pregled prednosti i nedostataka postojećih pristupa i metoda korišćenih u tezi i diskutuje o prednostima koje donosi pristup izložen u tezi. Automatizacijom prikazanog metodološkog pristupa, razvoj IS postaje mnogo efikasniji naročito ako se ima u vidu da ovaj pristup ima veliki potencijal da postane opšta metodologija razvoja IS. Ključne reči: Softverska proizvodna linija, Modeli karakteristika, Višenivovsko fazno konfigurisanje, NGOSS okviri: eTOM i SID, Generisanje modela, Konkretizacija telekomunikacionog domena, Transformacija modela, Biznis i IT poravnanje, Ponovno korišćenje softvera, Metodologija razvoja IS Naučna oblast: INFORMACIONI SISTEMI, Uža naučna oblast: METODOLOGIJA RAZVOJA IS, UDK: 004 AN APPROACH TO BUILD INFORMATION SYSTEM OF TELECOMMUNICATION COMPANY BASED ON MODELS ABSTRACT: This work gives definition of a methodological approach to build information system of telecommunication company based on models, through consolidation of general approaches of IS development and a specific initiative within telecommunication area:  MDA (Model Driven Architecture), an approach to software development that was set as a standard and promoted by OMG (Object Management Group).  EA (Enterprise Architecture), an approach to simultaneous development of Business and IT Architecture of a company. TOGAF (The Open Group Architectural Framework) is the most common and best known architecture framework and method for enterprise architecture development.  NGOSS (New Generation Operations Systems and Software), a program being developed by Telemanagement Forum that represents a framework for development and implementation of „Operation and Business Support Systems – OSS/BSS” within telecommunication industry.  SPL (Software Product Line), a development of IS over Software Product Lines, represents a modern approach to automation of domain-specific model-driven software development, where a software product family, and not a single software product, is developed through domain engineering. The methodological approach is based on a software product line specific to telecommunication domain which is based on NGOSS frameworks and models and which allows efficient building of Telecommunication Company IS through the following three distinct processes:  General domain engineering for telecommunication domain,  Domain engineering for telecommunication domain type of service,  Application engineering. In order to define a methodological framework for development of model-driven telecom operator IS it is necessary to have a good insight into the following dimensions of complexity in telecommunication domains: Functional Domains, Areas of Integrated Processes, Types of Telecommunication Services, IS Development Life-Cycles Phases, Specific Telecom Operators IS is being developed for. Afterwards, it is necessary to define both mutual relationships and dimension-shifting sequences. The basic initial scheme that gives classification of telecommunication domain by sub-domains and horizontal and vertical dependencies between sub-domains was defined based on eTOM and SID NGOSS Framework. The basic mechanism, named “Multi-level Staged Configuration”, was defined as technique which overcomes the complexity of telecommunication domain and works as a transition from one sub-domain to another. When such mechanism is applied to the basic initial classification scheme the result is a system for multi-level staged configuration of telecommunication domain. After that, it is possible to define a framework for telecommunication domain software product line that, through domain and application engineering, encompasses all previously mentioned dimensions of domain complexity. Due to multidimensional complexity of telecommunication domain, this approach implies specific domain engineering which consists of two levels: General domain engineering for telecommunication domain and Domain engineering for type of service. The General domain engineering for telecommunication domain; One of important steps of this domain process is defining system for Horizontal Multi-level Staged Configuration (HMLSC) HMLSC system is responsible for controlled and comprehensive definition of all initial Features Models by functional areas of telecommunication domain. The System is implemented through four HMLSC schemes. Within a functional area, models are horizontally dependent on each other and are constructed in accordance with defined dependencies between sub-domains. Besides Feature Models by functional areas, all necessary UML model patterns are also defined: Data Model Templates, Behavior Templates (applications and processes), etc. Another important step of General domain engineering for telecommunication domain is defining system for Vertical Multi-level Staged Configuration (VMLSC). This system is implemented through six configuration schemes. A main result of Vertical Multi-level Staged Configuration execution is implementation of vertical processes development through multi-level staged transformation of Feature Model, where the result (configuration) from the previous level represents input parameters for model construction on a lower level. The next important step is Defining system for Model Generation. Features Models represent well common and different features of product families. However, feature models do not serve their own purpose. They represent a guideline for construction of domain-specific data or behavior models. It means that feature models should be mapped into other models to transmit to them the necessary semantics. Mapping of MC into other models is performed through model generation schemes. Domain engineering for telecommunication domain type of service. In this section of Software Product Line (SPL) for telecommunication domain, the configuration schemes for Horizontal Multi-level Staged Configuration (HMLSC), defined in General Domain engineering, are further elaborated. These schemes normally represent rules and a path for defining models for type of service. Through use of these schemes, all initial Feature Models for IPTV service are defined by functional areas of telecommunication domain. In the second section, the schemes elaborated in General Domain Engineering for telecommunication domain that form the System for Vertical Multi-level Staged Configuration (VMLSC) are further elaborated. These schemes normally represent rules and a path for defining End-to-End Processes for type of service. Through use of these schemes, Feature Models are mutually annotated and a procedure of vertical processes development for IPTV service is defined. In the section of this domain process, are also defined schemes for automated configuration and generation of UML models of class diagrams and activity diagrams for IPTV service, based on UML model templates for IPTV and configurations of Feature Models. Application engineering for telecommunication domain allows specification and generation of a specific operator’s IS. Simultaneously, this part, as well as the entire methodological approach, is illustrated through step-wise tailoring and generation of a specific IS for a specific IPTV service operator. Configuration of a specific operator’s request for IS (Including IS) is performed first. After that, the IS is being tailored in detail using Vertical Multi-level Staged Configuration. During this process, generation of a specific telecom operator’s IS models is performed. Model-driven methodological approach to development of telecommunication company IS contributes to the solution of the following problems of IS development:  Solution of IT and Business Alignment, a problem that arises from differences in abstraction levels of Business and IT concepts.  Finding the way to overcome Multidimensional complexities of telecommunication domain.  Solution of the problem of IS development caused by Business Dynamism, because, besides being complex, Business is also highly dynamical due to constant and fast switches of technologies, user requests for new services, market competition, etc.  Allowing mass customization of services that remained unsolved by the existing methodological approaches, due to uncompleted solution of software reuse problem.  Supplements to general EA approaches and NGOSS domain EA with detailed models of telecommunication domain that are functional with specific telecom operators, through use of the existing ISs.  Allowing more efficient model transformation that represents one of the major general problems in MDA approach. This work closes with a review and a comparative overview of advantages and disadvantages of the existing approaches and methods used in the thesis and discuss the advantages brought by the approach the thesis sets forth. The automation of presented methodological approach brings more efficient IS development; especially bearing in mind the great potential of this approach for becoming the general methodology of IS development. Key words: Software Product Line, Feature Models, Multilevel Staged Configuration, NGOSS Frameworks: eTOM and SID, Model Generation, Concretization of telecommunication domain, Model Transformation, Business and IT Alignment, Software Reuse, IS Development Methodology. Scientific area: INFORMATION SYSTEMS, Special topics: METODOLOGY OF IS DEVELOPMENT, UDC: 004 S A D R Ž A J 1. UVOD ...................................................................................................................... 1 1.1. PREDMET ISTRAŽIVANJA ............................................................................................................... 1 1.2. CILJEVI ISTRAŽIVANJA ................................................................................................................... 2 1.3. MOTIVACIJA ................................................................................................................................. 3 1.4. PROBLEMI I HIPOTEZE .................................................................................................................. 6 1.5. NAUČNI DOPRINOS ...................................................................................................................... 8 1.6. SADRŽAJ TEZE ............................................................................................................................. 10 2. PREGLED PRISTUPA I METODA RELEVANTNIH ZA TEZU.......................................... 14 2.1. TRADICIONALNI PRISTUPI RAZVOJA IS ......................................................................................... 14 2.1.1. Funkcionalni i objektno orijentisani pristupi razvoja IS .......................................................... 15 2.1.2. Tradicionalni pristupi u odnosu na faze razvoja IS ................................................................ 17 2.1.3. Telekomunikacioni Informacioni Sistem (TIS) ........................................................................ 18 2.2. RAZVOJ I ARHITEKTURA VOĐENI MODELIMA (MDD I MDA) .......................................................... 21 2.2.1. Razvoj vođen modelima (MDD) ............................................................................................ 21 2.2.2. Arhitektura vođena modelima (MDA) .................................................................................. 22 2.2.3. Transformacije modela i CASE alati ...................................................................................... 24 2.3. ARHITEKTURA PREDUZEĆA (EA) .................................................................................................. 25 2.3.1. TOGAF - The Open Group Architectural Framework .............................................................. 25 2.3.2. NGOSS - The New Generation Operation System and Software ............................................. 29 2.3.2.1. Okvir za poslovne procese – eTOM .............................................................................................. 30 2.3.2.2. Okvir za kompanijske informacije –SID ....................................................................................... 36 2.4. SOFTVERSKE PROIZVODNE LINIJE (SPL) ....................................................................................... 38 2.4.1. Familija softverskih proizvoda ............................................................................................. 39 2.4.2. Metodološki okvir za razvoj softvera zasnovan na SPL inženjerstvu ...................................... 40 2.4.3. Modeli karakteristika (MK) ................................................................................................. 42 2.4.4. Mehanizmi za postepenu konkretizaciju u SPL inženjerstvu................................................... 46 2.4.4.1. Fazno konfigurisanje .................................................................................................................... 47 2.4.4.2. Višenivovsko konfigurisanje ........................................................................................................ 50 3. METODOLOŠKI OKVIR ZA IZGRADNJU IS TELEKOM OPERATORA ........................... 52 3.1. VIŠEDIMENZIONALNA SLOŽENOST RAZVOJA IS TELEKOMUNIKACIONOG DOMENA ...................... 54 3.2. TEHNIKA ZA SAVLADAVANJE SLOŽENOSTI I POSTEPENU KONKRETIZACIJU TELEKOMUNIKACIONOG DOMENA .......................................................................................................................................... 57 3.2.1. Osnovni mehanizam za višenivovsko konfigurisanje ............................................................. 57 3.2.2 Višenivovsko konfigurisanje telekomunikacionog domena ..................................................... 59 3.3. OKVIR SOFTVERSKE PROIZVODNE LINIJE ZA TELEKOMUNIKACIONI DOMEN ................................. 63 3.4. SPL OKVIR ZA DOMENSKI INŽENJERING TELEKOMUNIKACIONOG DOMENA ................................. 67 3.4.1. Opšti domenski inženjering telekomunikacionog domena ..................................................... 67 3.4.2. Domenski inženjering telekomunikacionog domena za Tip servisa ........................................ 69 3.4.3. Rukotvorine domenskog inženjeringa za telekomunikacioni domen ...................................... 70 3.5. SPL OKVIR ZA APLIKACIONI INŽENJERING TELEKOMUNIKACIONOG DOMENA ............................... 73 3.5.1. Aplikacioni inženjering telekomunikacionog domena............................................................ 73 3.5.2. Rukotvorine aplikacionog inženjeringa za telekomunikacioni domen .................................... 74 4. DETALJNI OPIS METODOLOŠKOG PRISTUPA ZA IZGRADNJU IS TELEKOM OPERATORA ............................................................................................................... 77 4.1. DETALJNI OPIS OPŠTEG DOMENSKOG INŽENJERINGA TELEKOMUNIKACIONOG DOMENA ............ 77 4.1.1. Definisanje sistema za horizontalno višenivovsko fazno konfigurisanje (HVFK) telekomunikacionog domena ........................................................................................................ 78 4.1.1.1. Osnovi mehanizam za kreiranje modela karakteristika iz konfiguracije .......................................... 80 4.1.1.2. Definisanje sistema za HVFK kreiranje MK za funkcionalni domen Upravljanje odnosom sa korisnikom ............................................................................................................................................... 81 4.1.1.3. Definisanje sistema za HVFK kreiranje MK za funkcionalni domen Upravljanje operativom servisa . 84 4.1.1.4. Definisanje sistema za HVFK kreiranje MK za funkcionalni domen Upravljanje operativom resursa 87 4.1.1.5. Definisanje sistema za HVFK kreiranje MK za funkcionalni domen Upravljanje odnosom sa Dobavljačem / Partnerom ........................................................................................................................ 90 4.1.2. Definisanje sistema za vertikalno višenivovsko fazno konfigurisanje (VVFK) telekomunikacionog domena ........................................................................................................ 94 4.1.2.1. Vertikalno višenivovsko konfigurisanje klase procesa „Razvoj proizvoda“ ...................................... 96 4.1.2.3. Vertikalno višenivovsko konfigurisanje klase procesa „Ispunjenje (Realizacija)“ ............................. 99 4.1.2.4. Vertikalno višenivovsko konfigurisanje klase procesa „Obezbeđenje održavanja“ ........................ 102 4.1.2.5. Vertikalno višenivovsko konfigurisanje klase procesa „Obezbeđenje kvaliteta“ ............................ 105 4.1.2.6. Vertikalno višenivovsko konfigurisanje klase procesa „Obračun“ ................................................. 108 4.1.2.7. Vertikalno višenivovsko konfigurisanje klase procesa „Obezbeđenje prihoda“ ............................. 111 4.1.3. Definisanje sistema za generisanje modela ........................................................................ 114 4.1.3.1. Definisanje Osnovnog mehanizma za generisanje modela ........................................................... 115 4.1.3.2. Sistem zaVišenivovsko Generisanje modela za klasu procesa - Razvoj proizvoda ......................... 116 4.1.3.3. Definisanje Šablona UML modela klasa – Specifikacija proizvoda ................................................. 120 4.1.3.4. Definisanje Šablona UML modela klasa – Specifikacija servisa ..................................................... 121 4.1.3.5. Definisanje Šablona UML modela klasa – Specifikacija resursa .................................................... 122 4.1.4. Testiranje sistema ............................................................................................................. 124 4.2. DETALJNI OPIS DOMENSKOG INŽENJERINGA TELEKOMUNIKACIONOG DOMENA ZA TIP SERVISA 125 4.2.1. Definisanje modela u sistemu za horizontalno višenivovsko fazno konfigurisanje (HVFK) za „IPTV“ Tip servisa ........................................................................................................................ 125 4.2.2. Definisanje sistema za vertikalno višenivovsko fazno konfigurisanje (VVFK) za IPTV tip servisa ................................................................................................................................................... 130 4.2.2.1. Deatalji osnovnog mehanizma za višenivovsko fazno konfigurisanje ............................................ 132 4.2.2.2. Vertikalno višenivovsko konfigurisanje klase procesa „Razvoj proizvoda“ za IPTV ........................ 134 4.2.2.2.1. MK Specifikacija IPTV proizvoda ........................................................................................ 135 4.2.2.2.2. MK Specifikacija IPTV servisa sa anotacijama ...................................................................... 135 4.2.2.2.3. MK Specifikacija IPTV resursa sa anotacijama ...................................................................... 139 4.2.2.2.4. MK Specifikacija resursa Dobavljača/Partnera sa anotacijama .............................................. 142 4.2.2.3. Vertikalno višenivovsko konfigurisanje klase procesa „Ispunjenje (Realizacija)“ za IPTV ............... 145 4. 2.2.3.1. MK Specifikacija IPTV proizvoda za nuđenje sa anotacijama ................................................ 145 4. 2.2.3.2. MK Konfiguracija i aktivacija IPTV servisa (Dizajn servisa) sa anotacijama ............................ 147 4. 2.2.3.3. MK Provisioning resursa sa anotacijama ............................................................................. 147 4. 2.2.3.4. MK Zahtev za realizaciju D/P sa anotacijama ...................................................................... 150 4.2.2.4. Vertikalno višenivovsko konfigurisanje klase procesa „Obezbeđenje održavanja“ za IPTV ............ 153 4. 2.2.4.1. MK Problemi proizvoda – IPTV sa anotacijama .................................................................... 153 4. 2.2.4.2. MK Problemi na IPTV servisu sa anotacijama ...................................................................... 154 4. 2.2.4.3. MK Problemi na resursu za IPTV ........................................................................................ 155 4. 2.2.4.4. MK Problemi na Resursu za D/P za IPTV .............................................................................. 160 4.2.3. Definisanje sistema za generisanje modela za tip servisa .................................................... 162 4.2.3.1. Šablon UML modela klasa za automatsko generisanje UML modela klasa – Specifikacija IPTV proizvoda ............................................................................................................................................... 163 4.2.3.2. Šablon UML modela klasa za automatsko generisanje UML modela klasa – Specifikacija IPTV servisa .............................................................................................................................................................. 165 4.2.3.3. Šablon UML modela klasa za automatsko generisanje UML modela klasa – Specifikacija IPTV resursa .............................................................................................................................................................. 166 4.2.3.4. Šablon procesa za klasu procesa - Razvoj Proizvoda .................................................................... 169 4.3. APLIKACIONI INŽENJERING TELEKOMUNIKACIONOG DOMENA .................................................. 173 4.3.1. Konfigurisanje zahteva za IS konkretnog telekom operatora ............................................... 173 4.3.1.1. Šema za konfigurisanje zahteva za IS konkretnog Telekom oeratora ............................................ 174 4.3.1.2. Model karakteristika tipova telekomunikacionih servisa ............................................................. 175 4.3.1.3. Model karakteristika domenskih šema i modela za tip servisa ..................................................... 177 4.3.2. Konfigurisanje IS telekom oeratora preko skupa izabranih VVFK šema ................................ 180 4.4.3. Generisanje IS konkretnog telekom operatora .................................................................... 193 4.4.3.1. Generisanje UML dijagrama klasa za Specifikaciju IPTV Proizvoda ............................................... 193 4.4.3.2. Generisanje UML dijagrama klasa za Specifikaciju IPTV servisa .................................................... 195 4.4.3.3. Generisanje UML dijagrama klasa za Specifikaciju IPTV Resursa .................................................. 196 4.4.3.4. Generisanje instance procesa – Razvoj proizvoda ....................................................................... 200 5. RELEVANTNI RADOVI SA UPOREDNOM ANALIZOM METODOLOŠKIH PRISTUPA 203 5.1. PREGLED RELEVANTNIH RADOVA.............................................................................................. 203 5.1.1. Pregled radova u vezi tradicionalnog pristupa razvoja IS .................................................... 203 5.1.2. Pregled radova relavantnih za MDD/MDA pristup razvoja IS .............................................. 205 5.1.3. Pregled radova u vezi EA pristupa ...................................................................................... 206 5.1.4. Pregled radova u vezi pristupa razvoja preko softvreskih proizvodnih linija ......................... 208 5.2. ANALIZA PRISTUPA ZA RAZVOJ IS .............................................................................................. 211 5.2.1. Prednosti i nedostaci postojećih pristupa ........................................................................... 211 5.2.2. Prednosti i nedostaci novog pristupa za razvoj IS telekomunikacione kompanije zasnovanog na modelima ............................................................................................................................... 218 6. ZAKLJUČAK ........................................................................................................... 220 6.1. OSTVARENI REZULTATI ............................................................................................................. 220 6.2. PRAVCI BUDUĆIH ISTRAŽIVANJA ............................................................................................... 222 7. LITERATURA .......................................................................................................... 225 1 1. UVOD Informacioni sistemi (IS) složenih kompanija za pružanje telekomunikacionih servisa pretežno su se razvijali sopstvenim resursima, kao samostalni izolovani sistemi. Raznovrsnost novih servisa koje jedna ovakva kompanija treba da pruži, veoma brz rast potreba i nove telekomunikacione tehnologije, zahtevaju promene ne samo u razvoju IS već i velike i sistematske promene u poslovanju. Novi modeli poslovanja treba da se razvijaju kroz složene i sveobuhvatne elektronske komunikacije sa svim vrstama partnera (e-poslovanje), a novi pristup razvoju IS treba da se zasniva na servisno orijentisanoj arhitekturi, na korišćenju gotovih softverskih proizvoda i servisa koji pružaju druge kompanije ili samostalni proizvođači softvera. Razvoj distribuiranog IS telekomunikacionih kompanija se danas svodi na integraciju već razvijenog sopstvenog softvera, novih gotovih softverskih komponenti i udaljenih softverskih servisa. 1.1. PREDMET ISTRAŽIVANJA Ovako postavljeni ciljevi razvoja telekomunikacionih sistema se realizuju preko specifičnih međunarodnih inicijativa i standarda telekomunikacionih asocijacija i preko opštih pristupa za razvoj složenih distribuiranih sistema. U ovom radu se čini pokušaj da se objedine opšti pristupi razvoja IS i specifične inicijative iz oblasti telekomunikacija:  MDA (Model Driven Architecture), pristup razvoju softvera koji je kao standard utvrdila i promoviše OMG (Object Management Group). U MDA se sistem razvija preko skupa platformski nezavisnih modela (PIM - Platform Independent Model) koji se u fazi implementacije formalno transformišu u odgovarajuće implementaciono okruženje (PSM - Platform Specific Model). Preporučuje se da se za izgradnju PIM-a koriste standardni "domenski modeli" (Domain Facility Models). 2  EA (Enterprise Architecture), pristup za razvoj arhitekture preduzeća, razvoj poslovanja (biznisa) i IT-a istovremeno. TOGAF (The Open Group Architectural Framework) je opšti najpoznatiji arhitekturalni okvir (framework) i metod za razvoj arhitekture preduzeća.  NGOSS (The New Generation Operations Systems and Software) program koji razvija Telemanagement Forum i koji predstavlja skelet (framework) za razvoj i primenu „Operation and Business Support Systems – OSS/BSS“ u telekomunikacionoj industriji. Jedan od osnovnih ciljeva NGOSS je da ponudi jedinstveni skup modela i alata za specifikaciju poslovnih procesa i softvera, koji ove procese treba da podrže u kompanijama, koje pružaju telekomunikacione usluge. NGOSS predstavlja industrijski standard za razvoj arhitekture preduzeća u oblasti telekomunikacija i predstavlja polazni domenski model za izgradnju PSM neke telekomunikacione kompanije.  SPL (Software Product Line), razvoj IS preko Softverskih proizvodnih linija, predstavlja savremeni pristup za automatizaciju razvoja softvera koji je zasnovan na domenskim, specifičnim modelima. Pristup koristi bogata iskustva iz industrijske proizvodnje, zato se za ovaj pristup kaže da je to „industrijalizacija razvoja softvera“. Ideja je da se kroz domensko inženjerstvo razvije familija softverskih proizvoda a ne pojedinačni softverski proizvod. Familija softverskih proizvoda se definiše kao grupa proizvoda koja ima zajedničke i različite karakteristike. Članovi familije se razlikuju međusobno po karakteristikama koje nisu zajedničke za sve članove te familije. Kroz aplikaciono inženjerstvo izborom različitih karakteristika dobija se član softverske familije proizvoda. 1.2. CILJEVI ISTRAŽIVANJA Osnovni ciljevi istraživanja u ovom radu su:  Definisanje metodološkog pristupa za razvoj informacionih sistema telekomunikacionih kompanija zasnovan na modelima. Pristup treba da objedini postojeće opšte metodološke pristupe za razvoj IS kao što su: MDA, EA, SPL, tradicionalni pristup i NGOSS pristup za razvoj IS u telekomunikacionoj 3 industriji, tako što će uzeti sve prednosti koje navedeni pristupi imaju i pokušati da reši nedostatke koje oni pokazuju.  Definisanje arhitekture softverske proizvodne linije za telekomunikacioni domen koja treba da čini osnovu pomenutog metodološkog pristupa. Ovakva SPL će biti zasnovana na NGOSS okvirima i modelima i omogućiće efikasnu izgradnju IS telekomunikacione kompanije.  Definisanje generičkih modela za telekomunikacioni domen u skladu sa NGOSS okvirima, a koji čine osnovu definisane SPL za telekomunikacioni domen. Ovde se pod generičkim modelima misli na šablone i instance UML modela, na šablone i instance Modela karakteristika (Feature Models FM). Za definisanje ovih modela pored NGOSS koristiće se i znanje iz postojećeg informacionog sistema kompanije Telekom Srbija TIS – Telekomunikacioni Informacioni Sistem.  Definisanje mehanizama za efikasnu transformaciju i generisanje modela koji treba da omoguće u definisanoj SPL za telekomunikacioni domen generisanje IS konkretne telekomunikacione kompanije kroz postepenu konkretizaciju generičkih modela koji se nalaze na različitim nivoima apstrakcije. 1.3. MOTIVACIJA Telekom industrija predstavlja sektor uslužne privrede koji ima ogromne prihode i koji znatno utiče na ekonomiju i život građana svake zemlje u svetu. Telekom kompanije, kao veoma složeni poslovno tehnički sistemi predstavljaju glavni zamajac u ovom sektoru usluga. One su decenijama poslovale lagodno zaštićene monopolom. Međutim poslednjih godina desila se velika transformacija tržišta u pružanju usluga u oblasti telekomunikacija jer je došlo do eksplozije konkurencije i novih servisa. Telekom kompanije nisu bile pripremljene za ovakve promene i počele su da zapadaju u ozbiljne probleme. Teško je bilo preći iz sveta regulisanih cena gde je uglavnom prodavan fiksni telefonski servis u nove potpuno drugačije uslove poslovanja. Dakle tržište telekomunikacionih i IT servisa u svetu se promenilo zauvek jer:  Nove tehnologije dolaze svakodnevno; 4  Zahtevi korisnika za novim servisima dolaze svakodnevno;  Nova konkurencija se pojavljuje svakodnevno. Mobilni operatori uvode nove informacione i video servise koji u pozadini zahtevaju novu infrastrukturu velike brzine. Operatori fiksnih linija izbacuju DSL i uvode nove servise kao što su internet televizija (IPTV – Internet Protocol TV) i video na zahtev (VOD – Video On Demand). Tržište konvergira, servisi konvergiraju, IP bazirana infrastruktura konvergira, korisnički uređaji konvergiraju ka jednom, unificiranom za sve servise. Pošto sve postaje bazirano na IP i pojavili su se fiksno-mobilni konvergentni servisi. Struktura industrije se takođe menja fundamentalno:  Infrastrukturni operatori postaju veleprodajni prodavci transportnih servisa i infrastrukture;  Konkurencija preseljava sve više i više na maloprodaju servisa;  Pošto servisi postaju bogatiji sa više sadržaja konkurenti iz sektora maloprodaje i zabave donose nove tržišne uloge. Pojavljuju se takozvani isporučioci sadržaja (Content provajderi). Radikalne promene na tržištu telekomunikacionih servisa zahtevaju radikalne promene u kompaniji. Međutim telekom kompanije nisu mogle da se lako adaptiraju na nastale promene iz sledećih razloga:  Mnogi poslovni procesi su iscepkani i usitnjeni i često su izolovani u organizacionim celinama;  Sistemske tehnologije su još više fragmentirane pa često se u kompaniji sreću svi proizvodi sistemskog softvera različitih proizvođača koji se pojavili do danas: operativni sistemi, sistemi za upravljanje podacima, programski jezici, različiti korisnički interfejsi, itd.;  Iscepkani (Fragmentirani) procesi i sistemske tehnologije značajno utiču na poslovnu sposobnost adaptacije na promene. To se vidi jasno u trenucima 5 lansiranja novog servisa ili reakcije na konkurenciju a posebno se vidi po predugačkim ciklusima „poručivanje-plaćanje“ (order-to-cash);  Operativni troškovi su neminovno viši sa veoma neefikasnim procesima i niskim nivoom automatizacije procesa Sa-kraja-na-Kraj (end-to-end);  Monopol je omogućavao poslovanje u kome nije bilo potrebe da se kompanije prilagođavaju korisniku i zbog toga su često sistemi i procesi bili dizajnirani za potrebe operatora a ne korisnika;  Ovako ukorenjena poslovna struktura koja je još uvek u mnogim fiksnim operatorima ima tendenciju da se veoma sporo menja. Da bi se nastali problemi rešili telekomunikacione kompanije treba da posluje kao takozvani Lean operatori. Termin Lean operator je skraćenica za adaptivnu kompaniju koja brzo reaguje koja isporučuje odličnu vrednost svojim korisnicima (servise) i odličan odgovor svojim akcionarima (profit) [ReCre 2005]. Termin „lean“ potiče iz proizvodne industrije, posebno iz proizvodnje automobila i 70 tih i 80 tih gde je Toyota bio pionir. Principi lean proizvodnje su široko prihvaćeni u proizvodnoj industriji širom sveta i zadnjih decenija su prihvaćeni u industriji usluga kao što je maloprodaja, bankarstvo i avio saobraćaj. Lean operatora karakterišu:  Dobro definisani poslovni procesi koji su visoko automatizovani,  Jedinstveni deljeni model podataka,  Unificirane i integrisane tehnologije. Visoki nivoi automatizacije procesa, visoki nivoi poslovne fleksibilnosti, visoki nivoi korisničkih servisa koji su spregnuti sa samoposluživanjem korisnika i sa veoma niskim operativnim troškovima je vizija za operatora 21 veka tzv. „lean“ operatora. Infrastruktura koja predstavlja neophodnu platformu za realizaciju Lean operatora naziva OSS/BSS (Operational Support System / Business Support System). OSS/BSS je jedinstvena upravljačka celina sastavljena od informacionog i telekomunikaciong sistema koji su međusobno uvezani i integrisani. Ovde više ne postoji granica između poslovnog i informacionog sistema već je to jedinstvena celina nazvana OSS/BSS. 6 OSS/BSS ne može da se izgradi po ad hoc sistemu i pristupom „parče po parče“ već mora da se primeni jedan sveobuhvatni metodološki pristup. Telemanagement Forum, međunarodna asocijacija, razvija industrijski standard NGOSS - The New Generation Operations Systems and Software, koji predstavlja referentni okvir za izgradnju OSS/BSS infrastrukture Lean operatora. U suštini to je integrisani skup okvira za poslovne procese, informacije i podatke, sistemske integracije i aplikacije. Međutim i pored pojave NGOSS okvira postoje veliki problemi u izgradnji OSS/BSS infrastrukture. NGOSS nije dovoljan, potrebno je da se on objedini sa opštim pristupima razvoja IS i da se iskoriste postojeća iskustva u razvoju IS koji su uglavnom razvijani na tradicionalan način. 1.4. PROBLEMI I HIPOTEZE Prethodno nabrojani problemi telekom operatora otvaraju niz problema kod izgradnje IS telekomunikacione kompanije (OSS/BSS), a za koje se traži rešenje u ovoj tezi:  Poravnanje biznisa i IT-a (IT and Business Alignment). Ovaj problem ukazuje na to da IT servisi ne mogu do kraja da zadovolje poslovne zahteve, odnosno IT nije poravnat sa biznisom. To potvrđuju i nedavna istraživanja koja su pokazala da 78% evropskih IT menadžera (CIOs) ukazuje upravo na to “IT is not align with business” [Silvius 2007]. Ovaj problem nastaje zbog razlike nivoa apstrakcija između Biznisa i IT servisa (aplikacija). To znači da postoji neusaglašenost apstraktnih nivoa i da je nivo implementiranih IT apstrakcija nizak. Naime sa jedne strane Biznis stalno ima zahteve da se automatizuju visoki nivoi biznis apstrakcija. Primer za visoki nivo biznis apstrakcije je proces Sa- kraja-na-Kraj koji u sebi sadrži niz olančanih aktivnosti. Sa druge strane IT obično nudi servise koje predstavljaju apstrakcije nižeg nivoa koje mogu da automatizuju pojedinačne aktivnosti ili delove aktivnosti procesa: Na primer: Unos radnog naloga, Kreiranje fakture, Kreiranje ugovora, itd.  Višedimenzionalna složenost poslovanja. Velika složenost je karakteristika poslovanja mnogih kompanija a naročito telekomunikacionih operatora. Telekom kompanije predstavljaju veoma složene sisteme i njihovo poslovanje obuhvata: procese koje se bave složenom tehničko-tehnološkom 7 infrastrukturom, administrativne procese, ekonomske i organizacione procese, itd. Kod izgradnje IS za ovakve kompanije veoma je teško je savladati tu veliku složenost. Za složene poslovne sisteme je teško precizno i sveobuhvatno specificirati poslovanje pa se često IS i izgrađuje za specifikaciju koja do kraja nije definisana (tako nastaju loši IS).  Dinamizam poslovanja. Pored toga što je složeno, poslovanje je i vrlo dinamično zbog stalnih i brzih promena u tehnologijama, zahteva korisnika za novim servisima, konkurencije na tržištu, itd. Zbog toga jednom izgrađen IS ne predstavlja kraj razvoja, već ga je potrebno stalno menjati u skladu sa promenama poslovanja. Problem nastaje kada brzina promena IS ne prati dovoljno brzo promene u poslovanju (realizacija ne prati specifikaciju sistema - korisničke zahteve).  Masovna kastomizacija servisa. Postojeći metodološki pristupi nisu u potpunosti rešili problem ponovnog korišćenja softvera (reuse). Slaba ponovna upotrebljivost otvara problem masovne kastomizacije softverskih servisa. Potreba za masovnom kastomizacijom javlja se u sledećim slučajevima: formiranje softverskog servisa u trenutku izvršavanja (Run Time kod Servisno Orijentisane Arhitekture - SOA); Cloud Computing načina pružanja servisa; razmeštaj istog softvera na mnogo mesta gde na svakom mestu je druga konfiguracija (zbog različitih funkcionalnih zahteva); više verzija softvera zbog promena u tehnologijama, itd.  NGOSS je samo okvir. TeleManagemnt forum je definisao NGOSS standard da bi omogućio sveobuhvatan i sistematizovan razvoj OSS/BSS platforme kao osnove za realizaciju Lean operatora. Opšti EA pristupi i NGOSS kao domenski EA omogućavaju klasifikovanje telekomunikacionog domena i organizovan pristup razvoju IS. Međutim njihovi okviri nemaju dovoljno detalja za izradu konkretnih detaljnih modela za telekomunikacioni domen. Zbog toga je neophodno koristiti i detaljno znanje iz postojećih IS koji funkcionišu kod konkretnih telekom operatora.  Neefikasan način transformacije modela. Način transformisanja platformski nezavisnog u platformski zavisan model je neefikasan, što je jedan od osnovnih 8 opštih problema u MDA pristupu. Razlog za to je postojanje velikog semantičkog jaza između modela koji ne može da se savlada direktnom transformacijom već mora da postoji postepena konkretizacija modela. U ovom radu će biti učinjen pokušaj da se ovi problemi jedinstveno reše. Iz prethodno definisanih problema može da se definiše sledeća istraživačka hipoteza: Osnovna naučna hipoteza teze je da je moguće izgraditi savremeni distribuirani servisno orijentisani informacioni sistem jedne telekomunikacione kompanije kombinovanjem novih svetskih standardnih specifikacija, postojećih informacionih sistema i savremenih opštih pristupa u razvoju IS. 1.5. NAUČNI DOPRINOS Neki opšti pristupi u razvoju informacionih sistema, odnosno softvera, pokazuju sve više nedostataka. Svi oni su obećali rešavanje problema "softverske krize", ali se elementi ove krize i dalje osećaju (skup razvoj, kašnjenje projekata, visok procenat potpunih promašaja). U poslednje vreme sve se više zagovara definisanje specifičnih "domenskih pristupa" u kome će se definisati specifični domenski modeli i metode. Ovaj rad prvenstveno pretenduje na naučni doprinos u oblasti razvoja informacionih sistema telekomunikacionih kompanija. Pored toga ovaj rad može da ima i bitan doprinos opštoj metodologiji razvoja IS. Osnovni naučni doprinosi ovog rada su:  Razvoj metodologije izgradnje IS telekomunikacione kompanije koja je bazirana na modelima specifične softverske proizvodne linije. Pristup koristi prednosti postojećih pristupa: Tradicionalni pristupi, EA, NGOSS, SPL i pretenduje na rešavanje njihovih nedostataka.  Izgradnja specifične proizvodne linije za telekomunikacioni domen koja se sastoji iz tri dela: Opšti domenski inženjering za telekomunikacioni domen, Domenski inženjering za Tip servisa, Aplikacioni inženjering telekomunikacionog domena.  Savlađivanje složenosti telekomunikacionog domena uvođenjem pet ortogonalnih dimenzija složenosti: Suštinski funkcionalni poslovni (pod)domeni složenog telekomunikacionog domena, Integrisani poslovni procesi (Sa-kraja- 9 na-Kraj), Tipovi telekom servisa koji se pružaju, Životni ciklus razvoja softvera, Konkretna telekom kompanija. Definisan je međusobni odnos ovih dimenzija, način i mehanizmi za kretanje kroz višedimenzioni prostor (elemente dimenzija) koji formiraju pojedine telekomunikacioni (pod)domene, kao i mehanizmi za prelazak iz (pod)domena u (pod)domen koji pri tome koriste rezultate (pod)domena koji prethodi.  Poravnanje IT-a i biznisa istovremenim sagledavanjem poslovanja i IS. Poslovanje je sagledano i sveobuhvatno i precizno specificirano. Definisani su procesi Sa-kraja-na-Kraj kao visoki nivoi biznis apstrakcija koje treba automatizovati (NGOSS eTOM klase procesa FAB – Fulfillment, Assurance, Billing and revenue assurance). Kroz tri nivoa specifične softverske proizvodne linije omogućen je efikasan razvoj IS što je i suština rešavanja poravnanja biznisa i IT-a.  Sistematska masovna ponovna upotreba softvera (Large Scale Reuse) u telekomunikacionom domenu je rešena kroz uvođenje dva nivoa domenskog inženjerstva u razvijenoj SPL za telekomunikacioni domen: Opšti domenski inženjering telekomunikacionog domena i Domenski inženjering za tip servisa na kojima su definisane neophodne rukotvorine. Kao i kod standardnih SPL, kroz Aplikacioni inženjering procesom konfigurisanja rukotvorina domenskog inženjeringa generiše se konkretni IS za konkretnog telekom operatora. Ovakav pristup rešava masovnu kastomizaciju softvera jer se gradi familija softverskih proizvoda iz koje se konfigurisanjem dobijaju članovi familije.  Postepena konkretizacija telekomunikacionog domena i premošćavanje semantičkog jaza preko tri nivoa softverske proizvodne linije i sistema za Višenivovsko fazno konfigurisanje.  Efikasna transformacija modela preko sistema za Višenivovsko fazno konfigurisanje: o Model karakteristika u Model karakteristika (Krojenje modela u trenutku izrade konkretnog IS), 10 o Model karakteristika (konfiguracija MK) u UML modele (generisanje UML modela na osnovu MK konfiguracije i šablona UML modela u trenutku izrade konkretnog IS).  Efikasna i automatska transformacija ključnih koncepata telekomunikacionog domena: Proizvod u Servis, Servis u Resurs, Resurs u Resurse partnera. Ovi koncepti pripadaju različitim funkcionalnim oblastima telekomunikacionog domena (različitim apstraktnim nivoima gde viši nivo predstavlja specifikaciju a niži realizaciju specifikacije) i njihovom automatskom transformacijom grade se klase procesa Sa-kraja-na-Kraj. Osnovni stručni doprinosi ovog rada su:  Izgradnja Modela karakteristika i UML šablona modela za telekomunikacioni domen za Tip servisa (npr. IPTV) kroz postupak Horizontalnog Višenivovskog Faznog Konfigurisanja, čime se detaljno modeluju (pod)domeni unutar jedne funkcionalne oblasti telekomunikacionog domena. Pored toga precizno se definišu i horizontalni uticaji jednog poddomena na drugi preko konfiguracija modela karakteristika.  Izgradnja integrisanih procesa Sa-kraja-na-Kraj za telekomunikacioni domen za Tip servisa (npr. IPTV) kroz postupak Vertikalnog Višenivovskog Faznog Konfigurisanja (Označavanje Modela karakteristika i UML šablona modela). Pri tome se precizno definišu vertikalni uticaji poddomena koji pripadaju različitim funkcionalnim oblastima (Izlaz, rezultat poddomena koji prethodi uzima se u obzir kod poddomena koji sledi). 1.6. SADRŽAJ TEZE Posle uvoda, u drugom poglavlju se daje pregled postojećih metodoloških pristupa i metoda koje su relevantne za ovu tezu. Prvo se opisuje Tradicionalni pristupi razvoja IS: Funkcionalni i Objektno orijentisani pristup, koji su uglavnom korišćeni za izgradnju postojećih IS. Kao primer za postojeći IS navodi se TIS – Telekomunikacioni Informacioni Sistem kompanije Telekom Srbija a.d. Drugi analizirani pristup je Razvoj i Arhitektura vođeni modelima (Model Driven Development – MDD i Model Driven Architecture – MDA). Treći pristup relevantan za tezu je Arhitektura preduzeća 11 (Enterprise Architecture – EA). Zatim se prikazuje NGOSS (The New Generation Operations Systems and Software) industrijski standard za oblast telekomunikacija. Sledi opis pristupa Softverske proizvodne linije (Software Product Lines – SPL) uz primenu posebne tehnike za savlađivanje složenosti u SPL inženjerstvu, Višenivovsko Fazno Konfigurisanje (Multilevel Staged Configuration). U trećem poglavlju daje se Metodološki okvir za razvoj IS telekom operatora zasnovan na modelima. Prvo se vrši sagledavanje svih dimenzija složenosti telekomunikacionog domena, njihovog međusobnog odnosa i definisanje redosleda kretanja kroz dimenzije. Zatim se definiše osnovni mehanizam za savlađivanje složenosti domena „Višenivovsko fazno konfigurisanje“. Posle toga sledi definisanje osnovne polazne šeme za višenivovsko fazno konfigurisanje telekomunikacionog domena na osnovu NGOSS okvira: eTOM i SID i osnovnog mehanizma za savlađivanje složenosti. Zatim se definiše okvir SPL za telekomunikacioni domen koji obuhvata sve dimenzije složenosti domena, kroz domenski i aplikacioni inženjering. Domenski inženjering u ovom pristupu je specifičan zbog višedimenzionalne složenosti telekomunikacionog domena i sastoji se iz dva nivoa: Opšti domenski inženjering telekomunikacionog domena i Domenski inženjering za tip servisa. Da bi se lakše sagledao ceo metodološki pristup u trećem poglavlju je prikazan samo opšti metodološki okvir pristupa, a onda u narednom četvrtom poglavlju i detaljno ceo pristup. Prvi deo poglavlja četiri detaljno opisuje osnovne korake opšteg domenskog inženjeringa za telekomunikacioni domen: Jedan od bitnih koraka je Definisanje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK). Ovaj sistem ima zadatak da kontrolisano i sveobuhvatno definiše sve početne Modele karakteristika po funkcionalnim oblastima telekomunikacionog domena. Sistem se realizuje pomoću četiri HVFK šeme. Modeli su horizontalno zavisni jedan od drugog i konstruišu se onako kako su definisane i zavisnosti između poddomena. Pored modela karakteristika koji predstavljaju vodilju definišu se i svi neophodni UML šabloni modela: Šabloni modela podataka, Šabloni ponašanja (aplikacije i procesi), itd. 12 Drugi važan korak je Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK). Ovaj sistem se realizuje kroz šest šema. Glavni rezultat izvršenja vertikalne višenivovske fazne konfiguracije je realizacija razvoja vertikalnih procesa kroz višenivovsku faznu transformaciju Modela karakteristika gde rezultat (konfiguracija) sa prethodnog nivoa predstavlja ulazne parametre za izradu modela na nižem nivou. Sledeći važan korak je Definisanje sistema za Generisanje Modela (GM). Modeli karakteristika lepo predstavljaju zajedničke i različite karakteristike familije proizvoda. Međutim modeli karakteristika nisu sami sebi svrha. Oni predstavljaju vodilju za izradu modela koji specificiraju podatke ili ponašanje nekog domena. To znači da modeli karakteristika treba da se preslikavaju u druge modele i da na njih prenesu potrebnu semantiku. Preslikavanje MK u druge modele se radi preko šeme za generisanje modela. U ovom delu poglavlja četiri daju se i jedan broj Šablona UML dijagrama klasa. Drugi deo četvrtog poglavlja odnosi se na detaljni prikaz domenskog inženjeringa za tip servisa. U ovom delu četvrtog poglavlja, razrađuju se dalje šeme koje su definisane u opštem domenskom inženjeringu za telekomunikacioni domen i koje predstavljaju Sistem za horizontalno višenivovsko fazno konfigurisanje (HVFK). Ove šeme inače predstavljaju pravila i putanju za definisanje modela za tip servisa. Koristeći ove šeme definišu svi početni Modele karakteristika po funkcionalnim oblastima telekomunikacionog domena za IPTV servis. U drugom delu četvrtog poglavlja, razrađuju se dalje šeme koje su definisane u opštem domenskom inženjeringu za telekomunikacioni domen i koje čine Sistem za vertikalno višenivovsko fazno konfigurisanje (VVFK). Ove šeme inače predstavljaju pravila i putanju za definisanje procesa Sa-kraja-na-Kraj za tip servisa. Koristeći ove šeme anotiraju se međusobno Modeli karakteristika i definiše postupak razvoja vertikalnih procesa za IPTV servis. U drugom delu četvrtog poglavlja definišu se i šeme za automatsko konfigurisanje i generisanje UML modela dijagrama klasa za IPTV servis na osnovu UML šablona modela za IPTV i konfiguracija modela karakteristika. 13 U trećem delu četvrtog poglavlja daje se detaljan prikaz Aplikacionog inženjeringa koji omogućava specifikaciju i generisanje IS konkretnog operatora. Istovremeno se ovaj deo a i ceo metodološki pristup ilustruje kroz postepeno krojenje i generisanje konkretnog IS za konkretnog operatora IPTV servisa. Prvo se vrši konfigurisanje zahteva IS konkretnog Telekom operatora (Obuhvat IS). Zatim se IS detaljno kroji primenom vertikalnog višenivovskog faznog konfigurisanja. Tokom ovog procesa vrši se generisanje modela IS konkretnog Telekom operatora. U petom poglavlju se daje pregled relevantne literature koja je korišćena u tezi (related work). Pored toga daje se uporedni pregled prednosti i nedostataka postojećih pristupa i metoda korišćenih u tezi i diskutuje o prednostima koje donosi pristup izložen u tezi. U zaključku, poglavlje šest, daju se rezultati ovoga rada i daje osvrt na moguće pravce budućih istraživanja. Na kraju sledi korišćena literatura. 14 2. PREGLED PRISTUPA I METODA RELEVANTNIH ZA TEZU Pristup izgradnji IS telekomunikacione kompanije zasnovan na modelima treba da obezbedi efikasan razvoj IS u oblasti telekomunikacija. Da bi se pristup definisao neophodno je analizirati dosadašnje relevantne pristupe u oblasti razvoja IS, treba uočiti njihove prednosti i nedostatke. Novi pristup treba da iskoristi dobre karakteristike postojećih pristupa i da reši neke ključne probleme koji su se javljali kod njihove primene u praksi. Ovde se opisuju sledeći pristupi i metode za izgradnju IS:  Tradicionalni pristupi razvoja IS: Funkcionalni i Objektno orijentisani pristup, koji su uglavnom korišćeni za izgradnju postojećih IS. Kao primer za postojeći IS navodi se TIS – Telekomunikacioni Informacioni Sistem kompanije Telekom Srbija a.d.  Razvoj i Arhitektura vođeni modelima (Model Driven Development – MDD i Model Driven Architecture – MDA),  Arhitektura preduzeća (Enterprise Architecture – EA),  NGOSS (The New Generation Operations Systems and Software) industrijski standard za oblast telekomunikacija,  Softverske proizvodne linije (Software Product Lines – SPL) uz primenu posebne tehnike za savlađivanje složenosti u SPL inženjerstvu, Višenivovsko Fazno Konfigurisanje (Multilevel Staged Configuration). U nastavku sledi kratak prikaz svakog od pomenutih pristupa. 2.1. TRADICIONALNI PRISTUPI RAZVOJA IS Najpoznatiji pristupi koji se mogu svrstati u tradicionalni razvoj IS su:  Funkcionalni i  Objektno orijentisani pristup. 15 Većina postojećih IS u svetu je upravo razvijan i realizovan primenom tradicionalnih pristupa. Glavna karakteristika ovih IS je da su oni dugo u eksploataciji (pripadaju realnom životu) i da je u njima nagomilano ogromno znanje o realnom sistemu, koje može da se iskoristi kod definisanja i izgradnje nekih novijih pristupa. U ovom radu je korišćeno znanje Telekomunikacionog Informacionog Sistema (TIS), razvijenog i implementiran u kompaniji Telekom Srbija, za izradu detaljnih modela (šablona modela) novog metodološkog pristupa. 2.1.1. FUNKCIONALNI I OBJEKTNO ORIJENTISANI PRISTUPI RAZVOJA IS Oduvek je jedan od velikih problema izgradnje IS bila složenost upravljanja njegovim razvojem i realizacijom. Funkcionalni i Objektno orijentisani pristupi su omogućili savlađivanje složenosti kroz dve tehnike:  Dekompozicija složenog sistema na manje delove koji su lakše savladivi,  Podela razvoja celokupnog IS na faze. Funkcionalni (strukturni) i Objektno orijentisani pristupi se koriste za postepeno dekomponovanje složenog sistema na manje složene delove (podsisteme), koji se zatim izgrađuju pojedinačno i na kraju integrišu u celokupan IS. Oba pristupa mogu da se primenjuju kroz ceo životni ciklus razvoja IS: Planiranje, Analiza, Projektovanje, Realizacija, Testiranje, Uvođenje u eksploataciju, Održavanje [LazMAB 2003]. Funkcionalni pristup je fokusiran na dekompoziciju funkcija (procesa). Na Slici 2.1. ovaj pristup se ilustruje primerom dekomponovanja funkcije Davanje servisa na korišćenje (primer je iz oblasti telekomunikacija) na prostije funkcije: Prijem zahteva korisnika, Ugovaranje proizvoda, Dizajn servisa, Aktivacija resursa. Najčešće korišćene tehnike kod ovog pristupa su:  Za planiranje razvoja sistema BSP (Business System Planning), [BSPM 1981],  Za dekompoziciju funkcija SSA (Strukturna Sistemska Analiza), [DeMarco 1978],  Za modelovanje podataka Prošireni Model Objekti Veze (PMOV), [Chen 1976]. 16 ProizvodKorisnik ResursServis Ugovaranje Proizvoda Prijem zahteva korisnika Dizajn Servisa Aktivacija Resursa Davanje Servisa na korišćenje FUNKCIONALNA DEKOMPOZICIJA OBJEKTNA DEKOMPOZICIJA Slika 2.1. Primer dekompozicije sistema korišćenjem tradicionalnih pristupa. Objektno Orijentisani pristup se bazira na konceptu Klase/Objekta [JacCJO 1992], [Booch 1994], [Wieringa 1998]. Na Slici 2.1. daje se primer, (takođe iz telekomunikacionog domena), dekomponovanih objekata: Korisnik, Proizvod, Servis, Resurs. Pomoću ovog pristupa sistem se opisuje kao skup objekata koji su međusobno u relaciji. Objekti u nekom sistemu su: fizički objekti, koncepti, apstrakcije ili sve ono što ima jasno značenje i jasne granice i razlikuje se od drugih objekata. Objekti i njihove veze predstavljaju se jasno definisanim konceptima. Najpoznatija tehnika objektno orijentisanog pristupa je UML (Unified Modeling Language) jedinstveni jezik za modelovanje [Souza 1998], [BoRuJa 1999]. UML daje sledeće tehnike za modelovanje:  Model slučajeva korišćenja (Use Case model)  Model komunikacije (interakcija)  Model klasa (Logički model)  Model komponenti (Fizički model)  Model razmeštanja 17 Pored toga UML definiše mehanizme za proširivanje za specijalne potrebe. 2.1.2. TRADICIONALNI PRISTUPI U ODNOSU NA FAZE RAZVOJA IS Prethodno prikazani metodološki pristupi su definisani sa aspekta savlađivanja složenosti razvoja softvera. Međutim tradicionalni pristupi mogu da se posmatraju i u odnosu na faze razvoja softvera. U nastavku su kratko dati opisi nekih tradicionalnih pristupa [LazNeš 1997] u odnosu na faze razvoja: “Vodopad” životni ciklus razvoja IS je sekvencijalni pristup razvoja softvera. Razvoj prolazi kroz nekoliko faza gde izlazi jedne faze predstavljaju ulaze u sledeće. Svaka faza je organizovana kao skup aktivnosti koje mogu da se izvršavaju od strane više ljudi istovremeno. Postoji nekoliko varijanti modela vodopada a jedna od njih ima sledeće faze: Definisanje strategije, Analiza postojećeg stanja, Projektovanje, Aplikativno modelovanje, Uvođenje, Održavanje. Prototipski razvoj softvera. Kod ovog načina razvoja softvera specifikacija zahteva korisnika se razvija pomoću prototipa. Prototip predstavlja verziju sistema koja sadrži sve njegove bitne karakteristike. Prototip se razvija kroz više iteracija u svakoj korisnik ocenjuje da li je on dobar i ako nije ide u novu iteraciju. Poslednja iteracija definiše specifikaciju realnog sistema. Prototip može da se usvoji ili potpuno odbaci. Operacionalni (transformacioni) pristup razvoju IS je imao za cilj da uvede revolucionarne promene u metodologiju razvoja softvera da razvoj potpuno formalizuje i automatizuje. Pristup ima sledeće faze:  Koristeći neki model Treće generacije, formirati semantički bogat model realnog sistema koji se analizira.  Prevesti dobijeni model u neki od modela Prve ili Druge generacije, u zavisnosti od softvera kojim se raspolaže i drugih činioca i na taj način implementirati bazu podataka na računaru. Postupak prevođenja sa semantički bogatijeg, na semantički siromašniji model može se uvek formalizovati, pa samim tim i automatizovati. 18 U metodologiji razvoja IS koja se ovde predlaže, kao model Treće generacije može da se koristi Prošireni model objekti-veze, najpopularniji semantički model podataka. Iterativno inkrementalni životni ciklus podrazumeva razvoj IS preko skupa manjih takozvanih „mini projekata“. Svaki „mini projekat“ predstavlja jednu iteraciju koja dodaje jedan inkrement funkcionalnosti sistema. Svaki „mini projekat“ prolazi kroz faze: Analiza, Logičko projektovanje, Fizičko projektovanje, Implementacija, Testiranje. Upravljačke aktivnosti: Start, Razrada, Izrada, Uvođenje, odvojene su od faza razvoja softvera. Upravljačke aktivnosti odnose se na svaku fazu razvoja softvera. U nastavku se kratko prikazuje jedan primer IS koji je razvijan i implementiran tradicionalnim pristupom. 2.1.3. TELEKOMUNIKACIONI INFORMACIONI SISTEM (TIS) Kao primer primene tradicionalnog pristupa u razvoju IS ovde se navodi Telekomunikacioni Informacioni Sistem (TIS), informacioni sistem koji funkcioniše više od jedne decenije u dve telekomunikacione kompanije: Telekom Srbija i Telekom Srpske u BIH [CveJMK4 2004]. Poseduje ogromno, provereno i detaljno znanje o telekom sistemu koje ne poseduju neki okviri iz telekomunikacija koji standardizuju razvoj IS u ovoj oblasti. U ovom radu znanje iz TIS-a će biti iskorišćeno za definisanje detaljnih modela novog metodološkog pristupa za razvoj IS telekomunikacione kompanije koji je baziran na modelima [Cve02 1995]. TIS je veoma složen informacioni sistem, koji automatizuje: tehničke, komercijalne, finansijske, administrativne, upravljačke i druge funkcije i procese telekomunikacione kompanije. Sastoji iz sledećih funkcionalnih podsistema koji su takođe veoma složeni (Slika 2.2.):  Upravljanje evidencijom telekomunikacionih resursa (Inventory Management), [CveMA1 1995], [CveLo 1995], [CveDa1 2005]  Upravljanje evidencijom servisa (Service Inventory Management)  Katalog servisa i tarifni planovi  Upravljanje korisnicima usluga (Customer Relationship Management)  Prodaja servisa i proizvoda [CveMA2 1995], [CveJOĐ 1999] 19  Održavanje telekomunikacionih kapaciteta i servisa, [CveJN 1995], [Cve01 1995], [CveJMK1 1996]  Billing - Fakturisanje ostvarenih usluga i proizvoda  Vođenje potraživanja korisnika usluga  Vođenje reklamacije korisnika usluga  Vođenje opomena korisnika usluga za neplaćene račune  Vođenje privremenih isključenja [NovJC 1996]  Vođenje tužbi za neplaćene račune Workflow Management System Jedinstveni model podataka Upravljanje evidencijom servisa Katalog servisa i tarifni planovi Upravljanje korisnicima usluga Prodaja servisa i proizvoda Održavanje telekom resursa i servisa Billing - Fakturisanje ostvarenih usluga i proizvoda Vođenje potraživanja korisnika usluga Vođenje reklamacija korisnika usluga Vođenje opomena korisnika za neplaćene račune Vođenje privremenih isključenja Vođenje tužbi za neplaćene račune Upravljanje evidencijom telekom resursa Slika 2.2. Arhitektura i podsistemi TIS-a. TIS je napravljen je kombinovanom primenom Funkcionalnog i Objektno orijentisanog pristupa. Njegove aplikacije rade nad jedinstvenim modelom podataka. Procesi su odvojeni od aplikacija i realizuju se kroz jedinstveni Sistem za upravljanje poslovima (Workflow engine), Slika 2.2. [CveJMK2 2001], [CveJMK3 2001]. Ceo sistem je realizovan u Oracle tehnologiji a evidentiranje telekomunikacionih kapaciteta je GIS (Geografski Informacioni Sistem) orijentisano [CveDa2 2005]. 20 TIS je u velikoj meri integrisan sa sistemom telekomunikacija u jedinstvenu celinu [Cve03 2005]. Na Slici 2.3. se vidi kako je TIS preko podsistema: Medijacije, Provisioninga, Upravljanja performansama, Upravljanje kvalitetom, povezan sa fizičkom telekomunikacionom infrastrukturom (servisne platforme i mreže). Ceo ovakav sistem radi nad jedinstvenom bazom podataka. Procesi se protežu od korisnika (Web) preko TIS-a do same fizičke opreme [CveNe 2010 ]. Horizontalni procesiEnd-To-End procesi W O R K F L O W E N G I N E Samoposluživanje korisnika (Web Self Care) Telekomunikacioni informacioni sistem (TIS) Servisne platforme i mreže (POTS, UMTS/3G, ISDN, ADSL, INTERNET, IPTV, VOD, L3VPN...) Deljeni model podataka Mediation (Resursi) Mediation (Servisi) Provisioning (Resursi) Konfiguracija i aktivacija servisa Upravljanje performansama resursa Upravljanje problemima na resursima Upravljanje kvalitetom servisa Upravljanje problemima na servisima Slika 2.3. Integracija TIS-a sa Telekomunikacionom infrastrukturom i opremom (OSS/BSS). Da bi se ilustrovala robusnost TIS-a evo nekih statističkih podataka o njegovoj eksploataciji u Telekom Srbija. Do sada je u TIS-u realizovano preko 30 miliona instanci procesa i preko dvesta miliona instanci aktivnosti tih procesa. U TIS-u je opisano preko 3 miliona korisnika, preko 7 miliona servisa, 4 miliona kablovskih parica, itd.. Svakog meseca se preko TIS-a izda oko 7 miliona faktura i rasknjiži isto toliko uplata. Svakog dana koristeći TIS radi oko 7 hiljada ljudi. TIS je više puta prezentiran u svetu: Orlando Amerika (Autodesk University), London (na svetskoj Billing konferenciji je bio nominovan za glavnu nagradu), u Telavivu Izrael (Amdocs kompanija), u Moskvi (kompanija Sistema), Oracle evropskom razvojnoj timu, itd. 21 2.2. RAZVOJ I ARHITEKTURA VOĐENI MODELIMA (MDD I MDA) Ovaj pristup se u nastavku prikazuje u tri dela:  Razvoj vođen modelima (Model Driven Development- MDD),  Arhitektura vođena modelima (Model Driven Architecture – MDA),  Transformacije modela i CASE (Computer Aided Software Engineering) alati. 2.2.1. RAZVOJ VOĐEN MODELIMA (MDD) Razvoj vođen modelima (Model Driven Development- MDD) je transformacioni razvoj softvera u kome se opšta specifikacija sistema formalno (automatizovano) transformiše u implementaciju u nekom definisanom okruženju [Pavel 2006]. Osnove MDD pristupa su ilustrovane na Slici 2.4. RAČUNARSKI NEZAVISNI MODELI Computer Independent Models - CIM PLATFORMSKI NEZAVISNI MODELI Platform Independent Models - PIM PLATFORMSKI ZAVISNI MODELI Platform Specific Models - PSM Transformacija CIM u PIM Transformacija PIM u PSM Slika 2.4. Osnove MDD pristupa. U MDD pristupu sistem se opisuje pomoću tri vrste modela:  Računarski nezavisni modeli (Computer Independent Models - CIM) opisuju neki domen preko zajedničkog rečnika za korisnika i projektanta koji se najčešće iskazuje verbalno, ponekad preko specifičnih grafičkih modela koji nisu pogodni za specifikaciju softvera. CIM predstavlja neformalni opis zahteva korisnika pomoću koncepata iz realnog sveta koji su nezavisni od bilo kojih računarskih koncepata. 22  Platformski nezavisni modeli (Platform Independent Models - PIM) opisuju sistem koristeći računarske koncepte koji su nezavisni od implementacione platforme (modeli su nezavisni od tehnologije).  Platformski zavisni modeli (Platform Specific Models - PSM) modeluju sistem koristeći koncepte nekog konkretnog računarskog okruženja. Oni se koriste za opis implementacije sistema. 2.2.2. ARHITEKTURA VOĐENA MODELIMA (MDA) OMG (Object Management Group) definiše standard za modelovanje nazivajući ga Arhitektura vođena modelima (Model Driven Architecture – MDA) [OMG 2012]. MDA predstavlja opšti metodološki okvir za MDD pristup zasnovan na UML jeziku za modelovanje. MDA predstavlja arhitekturu sa četiri nivoa apstrakcije (Slika 2.5.). MDA apstraktni nivoi su imenovani od M0 do M3. M0 je najniži nivo a M3 najviši nivo apstrakcije. Svaki nivo apstrakcije predstavlja pravilo za instanciranje nivoa ispod, odnosno nivo ispod mora da bude u skladu sa nivoom iznad. MDA apstraktni nivoi imaju sledeće značenje:  M0 nivo predstavlja najniži apstraktni nivo MDA standarda i odnosi se na koncepte koji predstavljaju konkretne objekte iz realnog sveta. Na ovom nivou se nalazi IS konkretnog preduzeća kao njegov model.  M1 nivo predstavlja apstraktni nivo na kome se nalaze modeli realnog sveta. To su konkretni softverski modeli odnosno model IS konkretnog preduzeća. U ovom modelu se definišu koncepti čije se instance na M0 nivou.  M2 nivo predstavlja apstraktni nivo na kome se definišu jezici modelovanja pomoću kojih se iskazuju modeli sa M1 nivoa. Modeli ovih jezika su zapravo meta modeli M1 modela, koji predstavljaju instance M2 modela M3 nivo predstavlja najviši nivo apstrakcije u MDA i na njemu se nalaze jezici kojima se definišu jezici za modelovanje sa M2 nivoa. Ovi jezici su meta jezici i predstavljaju meta modele sa M2 nivoa. MDA na ovom nivou ima definisan samo jedan meta jezik koji se naziva MOF (Meta Object Facility). MOF je jezik 23 u kome je definisan UML i ostali standardni MDA jezici modelovanja. MOF definiše i samog sebe. Meta Meta Model Meta Model Model sistema u skladu sa Sistem (IS) M3 M2 M1 M0 U skladu sa U U skladu sa Opisuje Meta-meta model je model meta-modela. On definiše pravila za izgradnju pravila za formiranje konstrukcija u nekom modelu (MOF). Meta-model je model modela. On definiše pravila za formiranje konstrukcija u modelu (Pravila za formiranje nekog UML modela - UML meta-model) Model IS - (UML model) Informacioni sistem - Implementacija Slika 2.5. MDA arhitektura sa četiri apstraktna nivoa. Na Slici 2.6. daje se primer apstraktnih nivoa na telekomunikacionom domenu. Svi MDD modeli konkretne telekom kompanije: CIM, PIM, PSM se nalaze na M1 nivou. Oni predstavljaju instance: CIM, PIM, PSM modela telekomunikacionog domena koji je definisan na nivou M2. CIM, PIM, PSM modeli na nivou M2 predstavljaju pravila za definisanje CIM, PIM, PSM modela na nivou M1. CIM, PIM, PSM modeli na nivou M2 se definišu u skladu sa NGOSS standardom, jezikom za opis karakteristika i profila napravljenih za telekomunikacioni domen. Na nivou 0 je IS konkretnog telekomunikacionog operatora. 24 M3 M2 M1 M0 MOF UML XMI CWM Meta Model Model Karakteristika (MK) CIM Telekom kompanije PIM Telekom kompanije PSM Telekom kompanije NGOSS Meta Model CIM Telekom domena PIM Telekom domena PSM Telekom domena Domenski MK jezik Ana.KORISNIK S.IPTV SERVISJe vlasnik IS konkretne Telekom kompanije <> <> <> <> <> <> Slika 2.6. Primer MDA arhitekture za NGOSS. 2.2.3. TRANSFORMACIJE MODELA I CASE ALATI MDA standard predviđa transformacije modela. Transformacija predviđa postojanje dva modela: izvornog i ciljnog. Svaki od ovih modela je napisan na različitom jeziku. Da bi mogla da se uradi transformacija iz izvornog u ciljni model neophodno je opisati pravila transformacije. MDA standard predviđa da se ova pravila pišu na standardnom jeziku za definisanje transformacija, koji se definiše kao proširenje meta jezika MOF. OMG je definisao MOF QVT (Query View Transformation) jezik za definisanje transformacija. Transformacije modela se opisuju u MOF QVT jeziku a zatim se ovaj opis koristi od alata za transformaciju. Tako bilo koji model se može transformisati u drugi ako su definisana pravila transformacije. MDA/MDD pristup je stvorio osnovu za automatizaciju razvoja softvera. Tako su se pojavili alati pod imenom CASE (Computer Aided Software Engineering) koji su 25 predstavljali podršku automatizaciji softvera. CASE su informacioni sistem o nekom informacionom sistemu [Neško02 2006]. Oni imaju nekoliko uloga:  Rečnik (Repository) svih resursa koji postoje u nekom IS,  Alate za podršku procesa razvoja IS,  Softverska podrška za razvoj IS vođen modelima. Primer CASE alata može se videti u radu [CveLaz 1988]. U radu [Neško01 1994] dat je primer CASE alat za razvoj IS postepenom konkretizacijom apstraktnih specifikacija. 2.3. ARHITEKTURA PREDUZEĆA (EA) Pre nešto više od dvadesetak godina nastao je novi pristup u razvoju IS poznat kao Enterprise Architecture (EA). Još tada su apostrofirani problemi koje treba rešavati:  Složeni IT sistemi – kompanije su trošile sve više para na izgradnju IT-a koji su sve više postajali neupravljivi.  Loše „poravnanje“ biznisa i IT-a – sve je teže bilo sa naraslim i sve skupljim IT sistemima zadovoljiti biznis potrebe EA je pristup za sveobuhvatno modelovanje arhitekture preduzeća, kada se istovremeno posmatraju i modeluju i poslovanje i IT. U njemu se čvrsto povezuju modeli organizacije i njenih poslovnih procesa sa softverskim arhitekturama i modelima implementacionog okruženja. Postoje više EA pristupa:  Zahmanov okvir [Zachman 1987],  TOGAF (The Open Group Architectural Framework) [TOGAF01 2011],  FEA (The Federal Enterprise Architecture ), [FEA01 2006],  Gartner [BiScKr 2005], U ovom radu koristiće će TOGAF i poseban EA pristup za domen telekomunikacija NGOSS (The New Generation Operating System and Software). 2.3.1. TOGAF - THE OPEN GROUP ARCHITECTURAL FRAMEWORK Prema TOGAF-u EA se sastoji iz četiri vrste arhitektura, Slika 2.7. [TOGAF02 2009], [TOGAF01 2011]: 26 POSLOVNA ARHITEKTURA ARHITEKTURA APLIKACIJA ARHITEKTURA PODATAKA TEHNIČKA ARHITEKTURA Slika 2.7. TOGAF arhitektura.  Poslovna arhitektura (Business architecture) – Opisuje korišćenje biznis procesa da bi se dostigli biznis ciljevi;  Aplikaciona arhitektura (Application architecture) – Opisuje specifikaciju aplikacija i njihov međusobnu povezanost i komunikaciju;  Arhitektura podataka (Data Architecture) – Opisuje organizaciju podataka preduzeća i pristup podacima;  Tehnička arhitektura (Technical Architecture) – Opisuje hardversku i softversku arhitekturu koja podržava aplikacije i njihove interakcije. TOGAF opisuje sebe kao okvir (framework), ali mnogo važniji deo TOGAF-a je metod razvoja arhitekture Architecture Development Method, poznat kao ADM. ADM je recept za kreiranje arhitekture (arhitekturalni proces), mnogo pre nego arhitekturalni okvir: ADM proces koji ima sledeće faze (Slika 2.8.):  Preliminarna faza (Preliminary). Priprema organizaciju za uspešno projektovanje pomoću TOGAF-a. Kroz pripremu se može naići na zahteve za novom arhitekturom preduzeća uključujući i definisanje organizaciono specifične arhitekture i definisanja principa arhitekture. U ovoj fazi mora da se obezbedi znanje i iskustvo o TOGAF-u [TOGAF02 2011]. 27  Faza A: Vizija arhitekture (Architecture Vision). Obezbeđuje da se definiše obuhvat i gruba vizija arhitekture kao i plan rada na njenom razvoju i razmeštaju.  Faza B: Poslovna arhitektura (Business Architecture),  Faza C: Arhitektura informacionog sistema (Information System Architecture),  Faza D: Tehnološka arhitektura (Technology Architecture) razvijaju arhitekturu na tri nivoa, Preliminarna faza A. Vizija arhitekture E. Mogućnosti i rešenja Upravljanje zahtevima C. Arhitektura informacionog sistema B. Poslovna arhitektura D. Tehnološka arhitektura G. Upravljanje implementacijom F. Planiranje migracije H. Arhitektura upravljanja promenama Slika 2.8. TOGAF ADM faze.  Faza E: Mogućnosti i rešenja (Opportunities and Solutions). Analiziraju se različite implementacione mogućnosti i identifikuju se glavni implementacioni projekti i grupišu u prelaznu arhitekturu. 28  Faza F: Planiranje migracije (Migration Planning). Analiziraju se troškovi, koristi i rizici. Razvijaju se detalji implementacije i plan migracije.  Faza G: Upravljanje implementacijom (Implementation Governance). Uzima se lista projekata koji su sortirani po prioritetima i specificiraju arhitekture za svaki projekat implementacije. Ove specifikacije sadrže i kriterijume za prijem (Acceptance tests) i listu rizika.  Faza H: Arhitektura upravljanja promenama (Architecture Change Management). Obezbeđuje neprekidno kontrolisanje i proces upravljanja promenama da bi se osiguralo da arhitektura odgovara potrebama preduzeća i maksimalnim biznis vrednostima.  Upravljanje zahtevima (Requirements Management). Obezbeđuje da se svaka faza TOGAF projekta bazira i proverava za date biznis zahteve. Viđen kao arhitekturalni proces TOGAF je komplementaran Zahmanovom pristupu koji je kategorisao artefakte preduzeća a TOGAF je dao proces za kreiranje tih artefakata. TOGAF vidi EA svet kao arhitekture koje su rangirane od visoko generičkih do visoko specifičnih (Slika 2.9.).  Generička arhitektura najvišeg nivoa se u TOGAF-u zove Osnovna arhitektura (Foundation Architectures). To su arhitekturalni principi koji mogu biti teorijski korišćeni u svim organizacijama u univerzumu. OSNOVNA ARHITEKTURA ZAJEDNIČKA SISTEMSKA ARHITEKTURA ARHITEKTURA ORGANIZACIJE ARHITEKTURA INDUSTRIJE PROSTOR POSLOVANJA ADMADM Slika 2.9. TOGAF - odnos između ADM i prostora poslovanja 29  Sledeći nivo specifičnosti Zajednička sistemska arhitektura (Common Systems Architectures). To su principi koji mogu da se vide u mnogo preduzeća ali ne baš u svim. TOGAF vidi sledeći nivo specifičnosti kao  Arhitektura industrije (Industry Architectures). Ovi principi mogu da se vide preduzećima koja predstavljaju deo istog domena kao na primer domen telekomunikacija.  TOGAF zove najspecifičniji nivo Arhitektura organizacije (The Organizational Architectures). To su arhitekture specifične za konkretno preduzeće. ADM obezbeđuje proces za upravljanje prelascima iz generičkih arhitektura u specifične. 2.3.2. NGOSS - THE NEW GENERATION OPERATION SYSTEM AND SOFTWARE NGOSS – predstavlja referentnu arhitekturu za telekomunikacionu industriju [ReCre 2005]. On sadrži skup okvira koji predstavljaju generičku klasifikacionu šemu za projektovanje kao i prikaz složenog domena kakv je telekom domen [TMF01 - TMF03], [NGOSS01 - NGOSS02]:  Okvir za rad za biznis procese – eTOM (Enhanced Telecom Operations Map) eTOM definiše sve glavne biznis procese unutar i van kompanije. Obezbeđuje okvir za rad i predstavlja zajednički jezik za opis biznis procesa koji se koriste u telekom kompaniji. Može biti korišćen kao katalog postojećih biznis procesa unutar servis provajdera, kao okvir za dokumentovanje softverski baziranih rešenja, ili prosto da omogući jasnu komunikaciju između servis provajdera i sistemskog integratora [eTOM01 - eTOM06].  Okvir za rad koji se odnosi na kompanijske informacije – poznat kao SID (Shared Information and Data Model). SID obezbeđuje iscrpan opšti informacioni model za kompletiranje telekom aktivnosti u kompaniji. Obezbeđuje „opšti jezik“ za proizvođače softvera i integratore u opisivanju upravljačkih informacija. Omogućava lakšu i efektivniju integraciju OSS/BSS preko softverskih aplikacija obezbeđenih od više prodavaca. Obezbeđuje koncepte i principe potrebne 30 da se definiše deljeni informacioni model, elemente ili entitete modela, biznis orijentisane UML modele klasa, dizajn orijentisani UML modele klasa i dijagrame sekvenci, odnosno obezbeđuje informacije sistemskog pogleda i podatke [Reilly 2007], [SID01 – SID19].  Okvir za sistemsku integraciju – poznat kao TNA (Technology Neutral Architecture). TNA definiše osnovne principe za razvoj NGOSS rešenja. Ovaj okvir za rad pokriva arhitekturalne izlaze uključujući opšte interfejse između komponenti (zvani ugovorni interfejsi), okvire za distribuciju, opšte mehanizme za komunikaciju i kurs i upravljanje procesima. Arhitektura se sa intencijom zove „Tehnološki – Neutralna“ pošto ne definiše implementacije [TNA01 – TNA03].  Okvir za aplikacije – poznat kao TAM (Telecom Application Map). TAM je dizajniran da ga koriste svi učesnici u softverskom lancu Telekoma. Može biti korišćen za različite stvari i dozvoljava i operatorima i isporučiocima širom sveta da ima isti okvir referenci za opisivanje sadašnjih i budućih potreba i namera. eTOM obezbeđuje okvir za telekom procese a TAM okvir za telekom aplikacije [TAM01 2010]. NGOSS definiše razvojnu metodologiju koja ima iterativni životni ciklus, i koja se zove SANR što predstavlja skraćenicu za pet koraka u razvojnoj metodologiji: Scope (Obuhvat), Analyze (Analiza), Normalize (Normalizacija), Rationalize (Racionalizacija), Rectify (Poravnanje). SANR definiše pristup za analizu, specifikaciju, dizajn i implementaciju rešenja izražen u NGOSS faktima kao što su: eTOM, SID, slučajevi korišćenja i ugovori. U nastavku sledi detaljniji opis dva NGOSS okvira eTOM i SID koji su od interesa za ovu tezu. 2.3.2.1. OKVIR ZA POSLOVNE PROCESE – ETOM eTOM je jedan od okvira NGOSS koji predstavlja referentni okvir ili model za kategorizaciju svih biznis aktivnosti koje jednog Telekom operatora [eTOM01 - eTOM06]. 31 Najvažnija svrha eTOM okvira je u utvrđivanju zajedničke definicije koja bi opisala elemente procesa pružaoca usluge odnosno definisanje „Standarda industrije“ za okvir biznis procesa. eTOM okvir odvaja strateške i procese životnog ciklusa od operativnih procesa u dve velike procesne oblasti, koje su prikazane kao dva veća pravougaonika u gornjem delu Slike 2.10. On takođe pravi razliku između ključnih funkcionalnih oblasti u vidu horizontalnih slojeva koji se protežu preko pomenutih procesnih oblasti. Treća glavna procesna oblast, se odnosi na upravljanje samim preduzećem, prikazana je kao odvojeno polje u donjem delu Slike 2.10:  Oblast procesa Operativa obuhvata sve operativne procese koji podržavaju upravljanje korisničkim operacijama i mrežom, kao i one koji omogućavaju neposredne operacije sa korisnikom. Ti procesi obuhvataju i svakodnevne procese podrške. Takođe ova oblast obuhvata upravljanje prodajom i odnose sa isporučiocem/partnerom. Upravljanje preduzećem Strategija, Infrastruktura, Proizvod Operativa Ispunjenje (Realizacija) Obezbeđenje Obračun i obezbeđenje prihoda Upravljanje odnosom sa Korisnikom Upravljanje operativom Servisa Upravljanje operativom Resursa Upravljanje odnosom sa Dobavljačem/Partnerom Strategija i izvršenje Upravljanje marketingom i ponudom Upravljanje razvojem Servisa Upravljanje razvojem Resursa Upravljanje razvojem lanca isporuke Upravljanje životnim ciklusom Infrastrukture Upravljanje životnim ciklusom Proizvoda Podrška operativnoj spremnosti Strateško i godišnje planiranje Upravljanje rizikom preduzeća Upravljanje efikasnošću preduzeća Upravljanje znanjem i istraživanjem Upravljanje osnovnim sredstvima i finansijama Upravljanje spoljnim odnosima i učesnicima poslovanja Upravljanje ljudskim resursima Slika 2.10. eTOM NGOSS okvir. 32  Oblast procesa Strategija, Infrastruktura i Proizvod obuhvata procese koji razvijaju strategiju preduzeća, koji planiraju, razvijaju i upravljaju isporukom i poboljšavanjem infrastrukture i proizvoda, i koji razvijaju i upravljaju Lancem isporuke. „Infrastruktura“ se ne odnosi samo na IT i mrežne resurse koji direktno podržavaju proizvode i servise. Ona takođe obuhvata operativnu i organizacionu infrastrukturu potrebnu za podršku marketingu, prodaji, procesima iz Servisnog i Lanca isporuke.  Oblast procesa Upravljanje preduzećem obuhvata one osnovne poslovne procese koji su potrebni za vođenje i upravljanje bilo kog velikog posla. Ti generički procesi su fokusirani kako na postavljanje i postizanje strateških korporativnih ciljeva, tako i na zadovoljavanje internih potreba u preduzeću. Ti procesi se ponekad nazivaju korporativnim funkcijama ili procesima, kao npr. procesi upravljanja finansijama, upravljanja ljudskim resursima, itd. Pošto se teži da ovi procesi imaju opštu podršku u preduzeću, oni se mogu povezati sa skoro svakim drugim procesom u preduzeću. eTOM okvir poslovnih procesa je razvijen da bi pomogao izgradnju i implementaciju procesa pružaoca servisa. eTOM je kao strukturisani katalog ili hijerarhijska klasifikacija elemenata procesa koji se mogu posmatrati sa sve više detalja. Kako u bilo kojoj klasifikaciji svaki element mora biti jedinstven. Na najvišem hijerarhijskom nivou su definisane dve kategorije procesa: Funkcionalne (tzv. horizontalne) grupe procesa i Vertikalne grupe procesa koji integrišu pojedinačne horizontalne procese u značajno krupnije funkcionalne celine, tzv. Sa-kraja-na-Kraj procese (eng. End-to-end):  Kada se sagledava grupa horizontalnih, funkcionalnih procesa, eTOM sledi strogu hijerarhiju u kojoj je svaki element pridružen ili vodi poreklo od samo jednog elementa u sledećem višem hijerarhijskom nivou. U nekoj klasifikaciji svaki element mora biti jedinstven, tj. mora biti naveden samo jednom.  Pored toga, eTOM namerava da pomogne pružaocima usluga da upravljaju svojim integrisanim poslovnim procesima Sa-kraja-na-Kraj. Sa tim na umu, eTOM pokazuje kako se od pojedenih elementarnih horizontalnih procesa izgrađuju integrisani vertikalni poslovni procesi Sa-kraja-na-Kraj. Te vertikalne grupe procesa Sa-kraja-na-Kraj obuhvataju hijerarhijski najviše horizontalne 33 grupe, pošto u hijerarhijskoj klasifikaciji neki element ne može biti pridružen ili voditi poreklo od više od jednog elementa na sledećem višem nivou. Horizontalne funkcionalne grupe procesa u oblasti Operative. U ovoj oblasti postoje četiri funkcionalne grupe procesa koje podržavaju gore razmatrane operativne procese i upravljanje operacijama za podršku korisnicima, uslugama, resursima i interakcijama sa isporučiocima/partnerima (videti Sliku 2.10.):  Upravljanje odnosom sa korisnikom (Customer Relationship Management, CRM): Ova horizontalna funkcionalna grupa procesa obezbeđuje osnovno znanje o potrebama korisnika i obuhvata sve funkcionalnosti potrebne za započinjanje, poboljšanje i zadržavanje odnosa sa korisnikom. Ona se tiče korisničkog servisa i podrške, bilo da je u pitanju usluga na prodajnom mestu, telefonska, web ili terenska usluga. Takođe, tiče se upravljanja zadržavanjem korisnika, unakrsne prodaje, proširenja prodaje i direktnog marketinga sa ciljem prodaje korisnicima. CRM takođe obuhvata prikupljanje podataka o korisniku i njihovu primenu za personalizovano, prilagođeno i integrisano pružanje usluga korisniku, kao i za pronalaženje prilika za povećavanje vrednosti korisnika za preduzeće. CRM se odnosi kako na konvencionalne maloprodajne odnose sa korisnikom, tako i na velikoprodajne odnose, kada preduzeće prodaje drugom preduzeću koje se bavi maloprodajom. CRM ne pravi razliku između manuelne ili automatizovane interakcije sa korisnicima, kao ni da li se komunikacija vrši pisanim putem, telefonom, web - baziranim transakcijama ili na neki alternativni način.  Upravljanje operativom Servisa (Usluge): Ova horizontalna funkcionalna grupa procesa je usresređena na znanje o uslugama (pristup, konektivnost, sadržaj, itd.) i obuhvata sve funkcionalnosti potrebne za upravljanje i održavanje ICT usluga koje zahtevaju korisnici ili koje su im predložene. Fokus je na pružanju i upravljanju uslugama, a ne na upravljanju mrežom ili IT-om koji predstavljaju potporu. Neke od funkcija uključuju kratkoročno planiranje kapaciteta za pojedinu uslugu, primenu dizajna usluge na specifične korisnike ili 34 rad na inicijativama za poboljšanje usluge. Te funkcije su tesno vezane za svakodnevno iskustvo sa korisnikom.  Upravljanje operativom Resursa: Ova horizontalna funkcionalna grupa procesa održava znanje o resursima (aplikacijama, računarskoj i mrežnoj infrastrukturi) i odgovorna je za upravljanje svim tim resursima (mrežama, IT sistemima, serverima, ruterima, itd.) koji se koriste za pružanje i podršku uslugama koje zahtevaju korisnici ili koje su im predložene. Ovi procesi garantuju da mrežna i IT infrastruktura podržava pružanje zahtevanih usluga Sa- kraja-na-Kraj. Svrha ovih procesa je da obezbede da infrastruktura radi stabilno, da je pristupačna uslugama i zaposlenima, da je održavana i da, direktno ili indirektno, odgovara potrebama usluga, korisnika i zaposlenih. Takođe ima osnovnu funkciju da sakuplja podatke o resursima (iz elemenata mreže i/ili sistema za upravljanje elementima mreže), i da ih tada integriše, koreliše i u mnogim slučajevima, sumira i prosledi relevantnu informaciju sistemima za upravljanje uslugom, ili da preduzme akciju na odgovarajućem resursu. U svetu e-Poslovanja je upravljanje aplikacijama i računarima jednako bitno kao i upravljanje resursima mreže. Šta više, mrežni, računarski i aplikacioni resursi sve više moraju biti upravljani na zajednički i integrisani način.  Upravljanje odnosom sa isporučiocem/partnerom: Ova horizontalna funkcionalna grupa procesa podržava središnje operativne procese. Procesi uključuju izdavanje i praćenje porudžbina do isporuke, prilagođavanje zahtevanih porudžbina spoljnim procesima, postupanje sa problemima, provera izdavanja računa i odobravanje plaćanja, kao i upravljanje kvalitetom isporučioca i partnera. Važno je napomenuti da kada preduzeće prodaje svoje proizvode partneru ili isporučiocu, to se vrši kroz CRM procese preduzeća koje se u tom slučaju ponaša kao isporučilac. Ovi procesi ovde pokrivaju samo slučaj kada preduzeće kupuje usluge. Vertikalni procesi Sa-kraja-na-Kraj u oblasti operative. Grupe procesa na Vertikalnom Nivou 1, predstavljaju gledište na procese poslovanja Sa-kraja-na-Kraj. Ovo gledište je značajno osobama koje su odgovorne za menjanje, 35 izvršavanje i upravljanje procesima Sa-kraja-na-Kraj. Ti procesi teže da premoste granice organizacije, tako da je efektivnost tih procesa u oblasti nadležnosti višeg menadžmenta, a posebno generalnog direktora (CEO - Chief Executive Officer). Ovi ljudi su više zainteresovani za krajnje rezultate procesa i kako oni sveukupno efektivno podržavaju korisničke potrebe, nego za brigo o IT ili posebnim radnim grupama koje treba da rade zajedno kako bi ostvarile rezultat. Oblast operativnih procesa sadrži i vertikalne grupe procesa koji se ponekad nazivaju procesi korisničkih operacija:  Ispunjenje (Realizacija) (Fulfillment): Ova vertikalna grupa procesa je odgovorna za blagovremeno i ispravno pružanje korisnicima proizvoda koje su tražili. Ona prevodi korisnikove poslovne ili lične potrebe u rešenje koje se može isporučiti korišćenjem konkretnih proizvoda iz portfolija preduzeća. Ovaj proces obaveštava korisnike o stanju njihovog zahteva, garantuje blagovremeno ispunjenje i jemči zadovoljstvo korisnika.  Obezbeđenje (Assurance): Ova vertikalna grupa procesa je odgovorna za izvršavanje proaktivnog i reaktivnog održavanja u cilju obezbeđenja da usluge koje se pružaju korisnicima budu neprekidno raspoložive i u skladu sa nivoima performansi definisanim SLA (Service Level Agreement) ili QoS (Quality of Service). Ona neprekidno nadgleda stanje i performanse resursa kako bi proaktivno otkrila moguće kvarove. Prikuplja podatke o performansama i analizira ih sa ciljem da prepozna moguće probleme i reši ih bez uticaja na korisnika. Upravlja SLA i izveštava korisnika o performansama usluge.  Fakturisanje i upravljanje prihodom (Billing and Revenue Assurance): Ova vertikalna grupa procesa je odgovorna za prikupljanje odgovarajućih zapisa o korišćenju, izdavanju blagovremenih i tačnih računa, za pružanje prethodnih obaveštenja za obradu uplata korisnika. Uz to, ona obrađuje upite korisnika o računu, daje stanje prigovora i odgovorna je za rešavanje problema sa blagovremeno izdavanjem računa. Ova grupa procesa takođe podržava pretplatu za usluge. 36  Operativna podrška i spremnost: Ova vertikalna grupa procesa Sa-kraja-na- Kraj je odgovorna za pružanje upravljačke, logističke i administrativne podrške prethodno definisanim grupama vertikalnih procesa. Uopšte, procesi Sa-kraja- na-Kraj u ovoj grupi se tiču aktivnosti koje su manje u realnom vremenu i koje se manje odnose na individualne korisnike i usluge, a više na obezbeđenje da se ostali vertikalni procesi s-kraja-na-kraj efikasno izvršavaju. Jasan primer za ovaj tip procesa su procesi upravljanja brojem osoblja koji se koriste za efikasan rad Kontakt centara. Oni odslikavaju potrebu nekih preduzeća da podele svoje procese na neodložne korisniku okrenute operacije u realnom vremenu i ostale procese koji deluju kao „druga linija“ ili „zaleđe upravljanja operativnim procesima“. Razdvajanje, definisanje i izvršavanje ovih procesa može biti ključno za korišćenje povoljnosti e-Poslovanja, i posebno je značajno za uspešnu implementaciju korisničkog sopstvenog upravljanja (Customer Self Management). 2.3.2.2. OKVIR ZA KOMPANIJSKE INFORMACIJE –SID Model biznis pogleda Zajednički korišćene Informacije i Podaci (Shared Information and Data – SID) može se posmatrati kao prateći model eTOM-a, s obzirom da pruža referentni model informacija i podataka i zajednički vokabular informacija i podataka iz perspektive biznis entiteta [Reilly 2007], [SID01 – SID19]. Model biznis pogleda koristi koncepte domena i združenih biznis entiteta (ili poddomene) za kategorizaciju biznis entiteta, da bi se na taj način smanjilo dupliranje ili preklapanje. Zajedno sa eTOM-om SID model pruža kompanijama ne samo pogled na procese njihovih biznisa, već i ukupan pogled. SID daje definiciju „stvari“ na koje će biznis procesi opisani u eTOM-u uticati. U NGOSS-u SID i eTOM u kombinaciji nude način definišu biznis potrebe. Slično, kao što eTOM-a raščlanjuje procese i SID omogućava raščlanjivanje informacija. Prvi nivo raščlanjivanja predstavlja velike oblasti, koja se nazivaju domeni. Oni predstavljaju koncept od ključnog interesa za svako preduzeće iz oblasti 37 informacija i komunikacija. Domeni obuhvataju koncepte kao što su Tržište/Prodaja (Market/Sales), Proizvod (Product), Korisnik (Customer), Usluga (Service), Resurs (Resource), Dobavljač/Partner (Supplier/Partner) i Preduzeće (Enterprise), kao što je prikazano na Slici 2.11. Svaki domen se dalje raščlanjuje u kohezivne zbirke entiteta koji karakterišu domen. Ove zbirke entiteta zovu se Združeni poslovni entiteti (Aggregate Business Entities – ABEs). Tako na primer Proizvod ima sledeće združene poslovne entitete (Slika 2.11.: Specifikacija proizvoda, Nuđenje proizvoda, Performanse proizvoda, itd. UML notacijom (dijagrami klasa) u SID-u se opisuju poddomeni i odnosi između njih. Tako na primer na Slici 2.12. definišu se odnosi između: Proizvoda, Servisa, Resursa. Proizvod može biti pojedinačni (Product Component) ili kompozitni (Product Bundle). Customer Market / Sales Product Service Supplier / Partner Common Business Product Product Specification Product Offering . Plan Product Performance Customer Customer Interaction Customer Order Customer Statistic Customer Problem Customer SLA Applied Cust . Bill. Rate Customer Bill Customer Bill Collection Customer Bill Inquiry Market Strategy & Plan Market Segment Marketing Campaign Competitor Service Service Specification Service Applications Service Configuration Service Usage Supplier/Partner S/P Plan S/P Interaction S/P Product S/P Order S/P SLA Party Location Business Interaction Policy Agreement Service Strategy & Plan Service Trouble Service Test Resource Resource Specification Resource Topology Resource Configuration Resource Performance Resource Usage Resource Strat . & Plan Resource Trouble Resource Test S/P Problem S/P Statistic S/P Bill Inquiry S/P Payment S/P Performance S/P Bill (Under Construction) Resource Enterprise surs Preduzeće Strat . Prod. Portf Product Usage Statistic Contact/Lead/Prospect Sales Statistic Sales Channel Business Interaction Resource Performance Resource Trouble Resource Test Proizvod Specifika ija roizvoda Nuđenje proizvoda Perf rmanse p oizvoda Statistika korišćenja proizvoda Korisnik Interakcij korisnika Porudžbina korisnika Statistika korisnika Problem ko isnika Korisnik - SLA Faktura korisnika Tržište, Stra egij , Planiranje Tržišni segment Tržišna kampanja Konkur nt Kontakt/Vođenje/ r k Statistika prodaje Prodajni kanal S rvis Specifikacija Servisa Aplikacije servisa Konfiguracija servisa Performanse servisa Korišćenje servisa Dobav jač/Partner D p D i kcije D/ Proizvod D/P porudžbina D P Partija k cija Poslovna i akcija sa Ugovor Problemi na servisu Test servisa Res s Specifikacija r sursa Topologija resursa Konfiguracija resurs P rf rmanse resurs Eksploatacija re ursa Problemi na esursu T t resursa D/P problem D/P statistika D/P faktura - zahtevi D/P plaćanja D/ odziv D/P faktura Tržište/Prodaja Korisnik Proizvod Servis Res s Dobavljač/ artner Pr duzeće (...) Opšti posao Strategija i plan resursa Strat gija i plan servisa Strategija proizvoda Portfolio plan Faktura – zahtevi korisnika Kolekcija faktura korisnikaPrimena tarife na obračun Slika 2.11. SID domeni i ABEs na Nivou 1. Servis se definiše sa dva aspekta:  Pogled sa strane korisnika (Customer Facing Service)  Pogled sa strane resursa (Resource Facing Service) 38 Resurs može biti logički (Logical Resource) ili fizički (Physical Resource) Proizvod se realizuje preko servisa. Neki fizički resursi se mogu prodavati kao proizvod (npr. aparat mobilnog telefona). Proizvod se realizuje preko servisa i to preko Pogled na servisa sa aspekata korisnika. Ovaj se pak realizuje preko resursa. Slika 2.12. Odnos između ključnih SID klasa: Proizvod, Servis, Resurs. 2.4. SOFTVERSKE PROIZVODNE LINIJE (SPL) Razvoj IS preko Softverskih proizvodnih linija (Software Product Lines – SPL) predstavlja savremeni pristup za automatizaciju razvoja softvera koji je zasnovan na domenskim, specifičnim modelima. Pristup predstavlja pokušaj da se iskoriste bogata iskustva iz industrijske proizvodnje, kao što je automobilska industrija. Zbog toga se za ovaj pristup često kaže da je to „Industrijalizacija razvoja softvera“ [GreeWi 2004]. U osnovi je ideja je da se razvija Familija softverskih proizvoda umesto Pojedinačnih softverskih proizvoda. Service LogicalResourceResourceFacingService 0..n 1..n LogicalResourcesImplementRFS CustomerFacingService 0..n1..n CFServiceRequiresRFServices PhysicalResource 0..n0..n PResourceSupportsLResource 0..n 1..n PhysicalResourcesHostRFS ProductBundle ProductComponent Resource Product 0..n0..n ProductReferences 0..1 0..n ProductRealizedAsCFService 0..1 0..n ProductHasPhysicalResources 0..1 0..n ProductBundleComprisedOf 0..n 0..n ProductRealizedAsResource 39 2.4.1. FAMILIJA SOFTVERSKIH PROIZVODA Familija softverskih proizvoda može da se definiše kao grupa proizvoda koja ima zajedničke karakteristike koje se na engleskom nazivaju commonalities. Članovi neke familije proizvoda razlikuju od svih drugih proizvoda po karakteristikama koje nisu zajedničke za sve članove te familije. Te različite karakteristike, se nazivaju raznolikost, na engleskom variability [Parnas 1972 ], [Parnas 1976 ]. Familija proizvoda obezbeđuje kontekst u kome mnogi zajednički problemi članova familije mogu biti rešeni kolektivno. Na ovom kontekstu se zasniva koncept softverske proizvodne linije, koja obezbeđuje familiju sa širokim rešenjima i obezbeđuje upravljanje razlikama između članova familija. Umesto čekanja prilika da se pojavi potreba za ponovnu upotrebu (reuse), fabrika softvera sistematski sakuplja znanje kako proizvesti članove specifičnih familija proizvoda. Ta znanja se sakupljaju: kao sredstva (Assets) kao što su: uzori (Patterns), okviri za rad, modeli i alati i onda sistematski primenjujući ta sredstva na automatizaciju razvoja članova familija, redukujući trošak i vreme za tržište i poboljšavajući kvalitet proizvoda [GreeWi 2004]. Članovi familije softverskog proizvoda se proizvode kroz masovnu kastomizaciju raznolikosti. Na ovaj način se obezbeđuje sistematsko ponovno korišćenje (reuse) polazeći od opšteg ka pojedinačnom. Različite karakteristike, Raznolikost (Variability) se deli na [PoBoLi 2005]:  Raznolikost u vremenu  Raznolikost u prostoru Raznolikost u vremenu je postojanje različitih verzija rukotvorina (artefakata) koji su validni u različito vreme. Ova raznolikost se javlja najčešće zbog zastarevanja tehnologija i primene novih (evolucija softvera u vremenu). Raznolikost u prostoru je postojanje rukotvorina u različitim oblicima u isto vreme. (u različitim proizvodima). Danas je mnogo veći fokus na raznolikost u prostoru. Pored prethodnog raznolikosti se deli na:  Interna i 40  Eksterna raznolikost Eksterna raznolikost je raznolikost domenskih rukotvorina koji su vidljivi za korisnika, Interna raznolikost domenskih rukotvorina je skrivena od korisnika. 2.4.2. METODOLOŠKI OKVIR ZA RAZVOJ SOFTVERA ZASNOVAN NA SPL INŽENJERSTVU Metodološki okvir za razvoj softvera zasnovanog na SPL ima dvo kružni model SW inženjerstva, Slika 2.13. [GreeWi 2004], [PoBoLi 2005], [Kakola 2010]: - Domensko inženjerstvo - Aplikaciono inženjerstvo. Upravljanje proizvodom Inženjerstvo domenskih zahteva Dizajn domena Realizacija domena Testiranje domena Zahtevi Arhitektura Komponente TestoviD o m e n sk o in že n je rs tv o Domenske rukotvorine Inženjerstvo aplikacionih zahteva Dizajn aplikacije Realizacija aplikacije Testiranje aplikacije Zahtevi Arhitektura Komponente Testovi A p lik ac io n o in že n je rs tv o Aplikacije od 1 do N Slika 2.13. Okvir za SPL inženjerstvo. Softverska proizvodna linija se realizuje na fundamentalnim karakteristikama : 41  Razvoj za ponovno korišćenje (development for reuse) i  Razvoj sa ponovnim korišćenjem (development with reuse). Inženjerstvo domena (razvoj za ponovno korišćenje). Fokus je na proizvodnji svih potrebnih sredstava (asset range) relevantnih za ceo životni ciklus proizvodnje softvera (infrastruktura proizvodne linije): zahtevi, arhitektura, implementacija, testiranje. Razlika ovog pristupa od drugih reuse pristupa je da različita sredstva imaju svoje raznolikosti. Tako na primer zahtevi mogu da imaju eksplicitan opis specijalnih zahteva koja se primenjuju samo za odgovarajući podskup proizvodnih sredstava. Inženjerstvo aplikacija (Razvoj sa ponovnim korišćenjem), gradi krajnji proizvod na kraju infrastrukture proizvodne linije. Inženjering aplikacije je čvrsto vođen infrastrukturom proizvodne linije koja obično poseduje najveći deo funkcionalnosti koje su potrebne za novi proizvod. Raznolikosti koje su eksplicitno unutra modelovane obezbeđuju osnovu za izvođenje individualnih proizvoda. Kada se novi proizvod razvija projekat koji se sprovodi se podešava (set up). Onda se sakupljaju zahtevi i direktno kategorizuju i postaju deo proizvodne linije ili deo specifičnosti proizvoda (zajedničko ili raznoliko). U ovom koraku se razvoja preko 90% proizvoda može biti raspoloživo iz reuse a 10% mora biti razvijeno u narednim koracima. Često se za Softversku proizvodnu liniju kaže i fabrika softvera pa su ta dva naziva sinonimi. Pored toga termin Familija proizvoda je takođe sinonim za Softversku proizvodnu liniju. Jack Greenfield [GreeWi 2004], jedan od autora ideje o fabrikama softvera kaže sledeće: Fabrika softvera je konfiguracija jezika, uzoraka, okvira za rad i alata koji mogu da se koriste vrlo brzo (rapidly) i isplativo (cost-effectively) da proizvedu otvoreni (open-ended) skup varijanti standardnih proizvoda. Isti autor zatim definiše Fabriku softvera kao proizvodnu liniju vođenu modelima koja je automatizovana sa meta podacima koji su u modelima koristeći domen specifične jezike. 42 2.4.3. MODELI KARAKTERISTIKA (MK) Ključna tehnika za definisanje zajedničkih i različitih karakteristika familije proizvoda u SPL je Modelovanje karakteristika (Feature Modeling - FM) [KCHNP 1990]. Karakteristika (Feature) je osobina sistema koja je relevantna nekom učesniku u poslovanju i koristi se da uhvati zajedničko ili razliku između sistema u familiji [CzaEi 2000]. Karakteristika može da označava neku funkcionalnu ili nefunkcionalni karakteristiku na nivou zahteva (requirements), arhitekture, komponente, platforme ili na nekom drugom nivou. Dijagram karakteristika je stablo sa korenom koji predstavlja koncept (na primer softverski sistem) a njegovi čvorovi ispod njegove karakteristike. Postoji više notacija za predstavljanje Dijagrama karakteristika (Slika 2.14.) Obavezne i Opcione karakteristike k1 ... k k1 k2 k k2 ... FODA notacija Alternative karakteristike kj ... k k1 ... PROŠIRENA notacija Obavezne i Opcione karakteristike ...... Ekskluzivna ILI grupa kj ... k k1 ... ... ... Notacija sa KARDINALNOSTIMA k k1 k2 Obavezne i Opcione karakteristike ...... [1..1] [0..1] Grupa sa kardinalnošću <1-1> kj ... k k1 ... ... <1-1> Inkluzivna ILI grupa kj ... k1 ... ... Grupa sa kardinalnošću <1-j> kj ... k k1 ... ... <1-j> Eksluzivna ILI grupa sa opcionim karakteristikama kj ... k k1 ... ... Grupa sa kardinalnošću <0-1> kj ... k k1 ... ... <0-1> k Notacija sa ATRIBUTIMA k (a) k1 (a1) k2 (a2) Obavezne i Opcione karakteristike ...... [1..1] [0..1] Grupa sa kardinalnošću <1-1> kj (aj) ... k (a) K1 (a1) ... ... <1-1> Grupa sa kardinalnošću <1-j> kj (aj) ... k (a) K1 (a1) ... ... <1-j> Grupa sa kardinalnošću <0-1> kj (aj) ... k (a) K1 (a1) ... ... <0-1> Slika 2.14. Notacije za modelovanje karakteristika. 43 Modeli karakteristika - MK (Feature Models - FM) su Dijagrami karakteristika plus dodatne informacije kao što su opisi karakteristika, vremena vezivanja (binding times), prioriteti, učesnici poslovanja (stakeholders), itd. Modeli karakteristika su mehanizmi za domensko modelovanje kod softverskih proizvodnih linija. Oni eksplicitno prave razliku između zajedničkih i varijabilnih karakteristika i parametre varijacija predstavljaju direktno kao ograničenja (constraints). Oni su nezavisni od implementacione tehnologije i stoga su pogodni za mehanizme generalizacije i nasleđivanja. Elementi MK su karakteristike a ne objekti. Karakteristike mogu biti atomske ili kompozitne. Atomska karakteristika je jedinica koja ne može biti deljena. Kompozitna karakteristika kao suprotnost je jedinica sastavljena od ćerki karakteristika. Ćerke karakteristika koje učestvuju u kompoziciji mogu biti obavezne, opcione ili alternativne. Pored toga mogu biti u zavisnosti sa nekom drugom karakteristikom. Te zavisnosti se definišu preko različitih tipova ograničenja kao što je ekskluzija (isključenje, izuzetak), gde jedna karakteristika ne može da postoji zajedno u isto vreme sa drugom, ili inkluzija (uključivanje) gde jedna karakteristika zahteva postojanje druge. Predikati i kardinalnosti takođe mogu biti korišćeni za opis kompleksnijih odnosa. Model karakteristika može takođe da se lako preslika u XML šeme koje ih čine pogodnim za opis konfiguracije. Postoji više MK notacija: FODA notacija, Proširena notacija, Notacija zasnovana na kardinalnostima, Notacija sa atributima (parametrima). Grafičke MK notacije se daju u nastavku na Slici 2.14. [CzaHeEi 2004]. Za Dijagram karakteristika može da se pravi jedna ili više konfiguracija. Konfiguracija se sastoji iz karakteristika koje su odabrane u skladu sa ograničenjima definisanih varijabilnih karakteristika pomoću dijagrama karakteristika. Odnos između dijagrama karakteristika i konfiguracije se može porediti sa odnosom između klase i njene instance u objektno-orijentisanom programiranju [CzaHel 2005]. Proces izvođenja konfiguracije iz dijagrama karakteristika se naziva proces konfigurisanja. 44 Prethodno definisani koncepti tehnike modelovanja karakteristika ilustruju se Slikom 2.15. na kojoj je prikazan jedan MK iz domena telekomunikacija i jedna njegova konfiguracija. MK Standardni IPTV proizvod je koren - karakteristika koja definiše proizvod koji omogućava korisnicima gledanje televizije preko internet protokola. Na nižim nivoima ovaj proizvod je opisan karakteristikama koje u suštini predstavljaju osnovne IPTV funkcionalnosti koje korisnik može da dobije prilikom ugovaranja proizvoda. IPTV funkcionalnosti su:  TV program (TV uživo) je obavezna karakteristika koja ispod ima obaveznu karakteristiku Osnovni TV kanali i neobaveznu karakteristiku Dodatni TV kanali.  Video na zahtev je karakteristika koja je neobavezna i definiše mogućnost iznajmljivanja filmova i drugih sadržaja na ad hoc zahtev korisnika.  Snimanje sadržaja definiše, neobavezno, mogućnost snimanja emisija iz programa uživo i to Centralno na IPTV platformi ili Lokalno na kućnim uređajima. Obe ove karakteristike se date kao grupa koja sadrži najmanje jednu mogućnost izbora a najviše obe.  Gledanje IPTV je obavezna grupna karakteristika koja obuhvata karakteristike: Na jednom mestu i Na dva mesta, koje ukazuju na broj TV uređaja koji će se koristiti istovremeno za gledanje IPTV sadržaja (najmanje na jednom a najviše na dva televizora). Rezolucija slike je obavezna karakteristika koja se definiše kao grupa sa dve karakteristike: Visoka definicija i Standardna definicija. Mogu se izabrati obe istovremeno ili najmanje jedna.  Način pristupa je obavezna karakteristika koja definiše način pristupa do servisne IPTV platforme: Fiksna linija i Bežično. Moguća su oba pristupa ali uvek mora da postoji makar jedan. Prethodno opisani MK predstavlja primer ponude telekom operatora IPTV familije proizvoda, korisnicima usluga. Obavezne karakteristike su zajedničke za svaki proizvod 45 TV Program Rezolucija slike Način pristupa Fiksna linija Bežično Standardna definicija Visoka definicija Standardni IPTV proizvod Video na Zahtev Snimanje sadržaja Gledanje IPTV Na dva mesta Na jednom mestu LokalnoCentralnoDodatni TV kanaliOsnovni TV kanali [1..2] [1..2] [1..2] [1..2] TV Program Rezolucija slike Način pristupa Fiksna linija Standardna definicija Standardni IPTV proizvod Video na Zahtev Gledanje IPTV Na jednom mestu Osnovni TV kanali MK – Standardni IPTV proizvod Konfiguracija – Standardni IPTV proizvod Korisnika Konfigurisanje Slika 2.15. Model karakteristika Standardni IPTV proizvod i jedna njegova Konfiguracija. 46 a neobavezne omogućavaju kreiranje raznolikih proizvoda. Korisnik može da izabere neobavezne funkcionalnosti (karakteristike) koje želi da ima, kod kupovine ovog servisa. Biranjem karakteristika se radi kroz proces konfigurisanja. Na Slici 2.15. je prikazana jedna izabrana konfiguracija IPTV proizvoda. Korisnik je izabrao TV Program sa Osnovnim kanalima (Dodatne kanale nije) i funkcionalnost Video na zahtev. Nije izabrao mogućnost da snima IPTV sadržaj. IPTV program će gledati na jedom Televizoru. Rezolucija slike je Standardna definicija. Način pristupa do servisne platforme je preko Fiksne linije. MK na Slici 2.15. predstavlja Familiju IPTV proizvoda a Konfiguracija na istoj slici, Člana familije IPTV proizvoda. 2.4.4. MEHANIZMI ZA POSTEPENU KONKRETIZACIJU U SPL INŽENJERSTVU Postoje dva ekstrema slučaja pri izvođenju konfiguracija:  izvođenje konfiguracije direktno iz dijagrama karakteristika,  specijalizovanje dijagrama karakteristika na dole do potpune specijalizacije dijagrama karakteristika i onda izvođenje konfiguracije (koje je trivijalno). Dakle pored procesa konfigurisanja može da se definiše i proces specijalizacije MK. Proces Specijalizacije je proces transformacije koji uzima dijagram karakteristika i proizvodi drugi dijagram karakteristika tako da skup konfiguracija označen drugim dijagramom je podskup konfiguracija označen prvim dijagramom. Drugi dijagram je specijalizacija prvobitnog dijagrama. Potpuno specijalizovan dijagram karakteristika označava samo jednu konfiguraciju [CzaHel 2005]. Treba reći da ne mora uvek da postoji zainteresovanost samo za jednu specifičnu konfiguraciju. Na primer, Dijagram karakteristika koji još uvek sadrži nerešene raznolikosti može da se koristi kao ulaz za neku drugu fazu. Ovo je korisno prilikom generisanja specijalizovane verzije okvira (koji još uvek sadrži raznolikosti) ili kada se generiše aplikacija koja bi trebalo da podrži preostale raznolikosti u vreme izvršavanja (run time). Pored toga poslovni sistemi su složeni, familije softverskih proizvoda u takvim sistemima su složene. Kod definisanja familije proizvoda mogu se pojaviti 47 veoma glomazni MK sa kojima je teško upravljati. Zato su potrebni mehanizmi za savlađivanje složenosti i postepenu konkretizaciju MK. Mehanizmi za savlađivanje složenosti i postepenu konkretizaciju (Refinement) u SPL inženjerstvu koja se ovde koriste su [CzaHel 2005]:  Fazno konfigurisanje (Staged Configuration)  Višenivovsko Konfigurisanje (Multilevel Configuration) 2.4.4.1. FAZNO KONFIGURISANJE Modeli karakteristika definišu prostor konfigurisanja familije proizvoda. Član familije može da se specificira izborom željenih karakteristika iz MK poštujući ograničenja raznolikih karakteristika. Proces specifikacije familije proizvoda može da se izvede u fazama (ne mora odjedanput) gde svaka faza eliminiše neke izbore. Takav proces se onda zove Fazno konfigurisanje. Potreba za faznim konfigurisanjem se javlja kod lanca snabdevanja gde više partnera ima potrebu da radi nad jednom definisanom familijom. Fazno konfigurisanje se može postići specijalizacijom gde se u svakoj fazi primenjuje neki korak specijalizacije gde se u poslednjoj fazi na osnovu specijalizovanog dijagrama izdvaja konfiguracija. Potpuno specijalizovani MK ima samo jednu konfiguraciju. Fazna specijalizacija predstavlja fino granulisanje (fine-grained), fino eliminisanje raznolikosti kroz više faza. Fino eliminisanje raznolikosti se postiže preko koraka specijalizacije. Sintaksa i semantika koraka specijalizacije je prikazana na Slici 2.16. [CzaHel 2005]. Na Slici 2.17. ilustruje se fazno konfigurisanje na primeru MK koji se odnosi na Standardni IPTV proizvod. MK dijagram na vrhu sa Slike 2.17. i konfiguracija na dnu iste slike su već objašnjeni. Razlika je što ova konfiguracija nije dobijena direktno već primenom faznog konfigurisanja. Postepenom primenom koraka specijalizacije dobijen je specijalizovani MK – Standardni IPTV proizvod (MK dijagram u središnjem delu slike), a zatim je iz njega definisana već pomenuta konfiguracija. Smisao primene faznog konfigurisanja u ovom primeru je sledeći: 48 Profinjavanje kardinalnosti karakteristike k k1 [1..5] k k1 [2..4] Profinjavanje kardinalnosti grupe k k2 [2..3] k3k1 k k2 [2..2] k3k1 Uklanjanje grupisane karakteristike iz grupe k3 k k2 [2..3] k3k1 k k2 [2..2] k3k1 Selektovanje grupisane karakteristike k3 k k2 [2..3] k3k1 k k2 [1..2] k3k1 Dodela vrednosti atributu k k1 (Integer) k k1 (1 : Integer) Kloniranje usamljene karakteristike k k1 [1..5] k k1 [0..4] k2 Razvijanje reference dijagrama karakteristika k k1 k2 k3 k4 k k1 k2 k3 k4 k3 k4 Slika 2.16. Koraci fazne specijalizacije [CzaHel 2005]. 49 TV Program Rezolucija slike Način pristupa Fiksna linija Bežično Standardna definicija Visoka definicija Standardni IPTV proizvod Video na Zahtev Snimanje sadržaja Gledanje IPTV Na dva mesta Na jednom mestu LokalnoCentralnoDodatni TV kanaliOsnovni TV kanali [1..2] [1..2] [1..2] [1..2] TV Program Rezolucija slike Način pristupa Fiksna linija Standardna definicija Visoka definicija Standardni IPTV proizvod Video na Zahtev Gledanje IPTV Na dva mesta Na jednom mestu Dodatni TV kanaliOsnovni TV kanali [1..2] [1..2] [1..1] TV Program Rezolucija slike Način pristupa Fiksna linija Standardna definicija Standardni IPTV proizvod Video na Zahtev Gledanje IPTV Na jednom mestu Osnovni TV kanali MK – Standardni IPTV proizvod Specijalizovani MK – Standardni IPTV proizvod Operatora Konfiguracija – Standardni IPTV proizvod Korisnika Specijalizacija Konfigurisanje Slika 2.17. Primer faznog konfigurisanja. 50  MK – Standardni IPTV proizvod može da predstavlja opštu definiciju ovog proizvoda za ponudu koja je nezavisna od operatora.  Specijalizovani MK – Standardni IPTV proizvod Operatora opisuje karakteristike IPTV proizvoda koje nudi konkretni operatora. Ovo je uži MK u odnosu na početni koji nije u potpunosti specijalizovan.  Konfiguracija – Standardni IPTV proizvod Korisnika predstavlja izbor karakteristika IPTV proizvoda za konkretnog korisnika koji je izabran iz ponude konkretnog operatora. Jedna važna nepoznanica kod automatizacije procesa specijalizacije MK je koliko koraka specijalizacije treba da se izvrši ili bolje rečeno gde se treba zaustaviti sa specijalizacijom. Odgovor na ovo pitanje daje mehanizam koji se zove Višenivovsko konfigurisanje. 2.4.4.2. VIŠENIVOVSKO KONFIGURISANJE Višenivovsko konfigurisanje je oblik fazne konfiguracije gde se raspoloživi izbori u svakoj fazi predstavljaju posebnim modelima karakteristika. Ovaj koncept je dat u [CzaHel 2005] i ilustrovan na Slici 2.18. sa tri nivoa. Na svakom od n nivoa se kreira dijagram karakteristika ručno, a onda se izvršava fazna konfiguracija nad svakom od njih. Glavna ideja je da raspoloživi izbor konfiguracija u n-toj fazi se predstavi sa (verovatno specijalizovani) raspoloživim modelom karakteristika na nivou N na početku, u toj fazi. Na primer, izbori konfiguracija dostupni u fazi 0 se predstavljaju modelom karakteristika na nivou 0. Slično tome, izbor konfiguracija dostupnih u fazi 1 se predstavlja specijalizovanim modelom karakteristika na nivou 1, koji je raspoloživ na početku faze 1. Ručna konfiguracija modela karakteristika na nivou N u fazi N izaziva automatsku specijalizaciju modela karakteristika na nivou n + 1. Ta specijalizacija predstavlja onda raspoložive izbore konfiguracija u fazi n + 1. Tako svaka faza podrazumeva uputstvo za konfiguraciju (pre nego specijalizaciju) od strane odgovarajuće uloge. 51 Faza 0 Nivo 0 Nivo 0 - Model karakteristika Nivo 1 - Model karakteristika Nivo 2 - Model karakteristika Ručno konfigurisanje sa ulogom Faze 0 Nivo 0 - konfiguracija Automatska specijalizacija bazirana na konfiguraciji sa Nivoa 0 Specijalizovani Model karakteristika na Nivou 1 Ručno konfigurisanje sa ulogom Faze 1 Nivo 1 - konfiguracija Nivo 1 Faza 1 Automatska specijalizacija bazirana na konfiguraciji sa Nivoa 1 Specijalizovani Model karakteristika na Nivou 2 Ručno konfigurisanje sa ulogom Faze 2 Nivo 2 - konfiguracija Nivo 2 Faza 2 Slika 2.18. Višenivovsko konfigurisanje [CzaHel 2005]. Da bi se obezbedio poseban model karakteristika za svaki nivo potreban je mehanizam za specificiranje kako će automatski nivo n da bude specificiran bazirajući se na konfiguraciji na n -1 nivou. Ovaj mehanizam je jedan od osnovnih mehanizama koji se koristi u ovoj tezi i biće detaljno predstavljen i primenjen u narednim poglavljima. 52 3. METODOLOŠKI OKVIR ZA IZGRADNJU IS TELEKOM OPERATORA Metodološki okvir za izgradnju IS Telekom operatora treba da reši problem poravnanja biznisa i IT (Business and IT alignment) koji je i dalje jedan od fundamentalnih nerešenih problema u razvoju. Ovaj problem nastaje zbog toga što su savremeni poslovni domeni veoma složeni i stalno promenljivi u vremenu, pa je razvoj IS za takve poslovne sisteme neefikasan. Teško je savladati ogromnu složenost i teško je pratiti stalne promene poslovnih sistema koje nastaju zbog promena u organizaciji i tehnologijama. Da bi se savladala složenost i dinamizam poslovnog domena potrebna je:  Velika ponovna upotreba (Large Scale Reuse), tj. da se softverske rukotvorine (rezultati razvoja) ne razvijaju stalno iz početka,  Automatizacija procesa razvoja IS – tj. da se pojedine aktivnosti u razvoju u velikoj meri automatizuju korišćenjem savremenih softverskih alata I jedna i druga stavka ubrzava proces razvoja softvera čime se smanjuje ili potpuno eliminiše kašnjenje za promenama u poslovnom sistemu. Domen telekomunikacija, koji je tema ovog rada, je veoma složen. Ta složenost je višedimenzionalno jer domen mora da se posmatra i analizira sa više aspekata (dimenzija). Kako bi se ona savladala kod razvoja IS, neophodno je sagledati sve dimenzije složenosti. Složenost telekomunikacionog domena se ogleda u sledećem:  Visok nivo apstrakcija koje treba IT da podrži, kao što su poslovni ciljevi kompanije, složene poslovne kolaboracije, integrisani poslovni procesi Sa-kraja- na-Kraj, itd. Drugačije rečeno, postoji veliki semantički jaz između nivoa koncepata iz poslovnog domena i koncepata iz IT domena. 53  Sveobuhvatnost – domen obuhvata veliki broj raznorodnih funkcionalnih poddomena koji se odnose na: tehniku koja je veoma složena i sama se sastoji iz velikog broja tehničkih poddomena, administraciju, finansije, upravljanje, itd. Sve ovo ukazuje da telekomunikacioni domen karakteriše velika funkcionalna granularnost.  Međusobna uslovljenost pojedinih poddomena. Uobičajene standardne tehnike za savladavanje složenosti zasnovane na apstrakcijama, kao što je npr. dekompozicija domena na poddomene koji se dalje paralelno i nezavisno razvijaju, nisu dovoljne. Naime, pojedini poddomeni su međusobno uslovljeni i zavisni, odnosno rezultati razvoja iz jednog poddomena (specifikacije zahteva, projektantska rešenja, itd.) utiču i prenose se u druge poddomene. Metodološki okvir za razvoj IS telekom operatora mora da reši prethodno iznete probleme i u ovom poglavlju to rešenje obuhvata:  Sagledavanje svih dimenzija složenosti telekomunikacionog domena, njihovog međusobnog odnosa i definisanje redosleda kretanja kroz dimenzije.  Definisanje osnovnog mehanizma za savladavanje složenosti domena „Višenivovsko fazno konfigurisanje“.  Definisanje osnovne polazne šeme za višenivovsko fazno konfigurisanje telekomunikacionog domena na osnovu NGOSS okvira: eTOM i SID i osnovnog mehanizma za savlađivanje složenosti koji je prethodno definisan. Osnovnom polaznom šemom se specificiraju poddomeni i njihovi međusobni odnosi, odnosno sveobuhvatno definiše poslovanje telekomunikacione kompanije. Na osnovu polazne šeme za višenivovsko konfigurisanje definišu se detaljne šeme za horizontalno i vertikalno konfigurisanje. Ovaj sistem šema za višenivovsko fazno konfigurisanja predstavlja mehanizam ili tehniku koja omogućava savlađivanje složenosti i postepenu konkretizaciju telekomunikacionog domena.  Definisanje okvira softverske proizvodne linije za telekomunikacioni domen koji obuhvata sve dimenzije složenosti domena, kroz domenski i aplikacioni inženjering. Pristup razvoja IS preko softverskih proizvodnih linija sistematski 54 rešava ponovno korišćenje softvera (Sistematski reuse). Pored toga ovaj pristup omogućava automatizaciju procesa razvoja softvera, čime se rešava suštinski problem neefikasnog razvoja IS. Domenski inženjering u ovom pristupu je specifičan zbog višedimenzionalne složenosti telekomunikacionog domena i sastoji se iz dva dela: Opšti domenski inženjering telekomunikacionog domena i Domenski inženjering za tip servisa. U nastavku u poglavlju tri opisuje se ovaj Metodološki okvir za razvoj IS a po prethodno iznetim stavkama. U ovom poglavlju, da bi se lakše sagledao, okvir se daje grubo (prva dva nivoa dekompozicije) a u narednom poglavlju četiri i ceo pristup se objašnjava detaljno na još nižim nivoima dekompozicije. 3.1. VIŠEDIMENZIONALNA SLOŽENOST RAZVOJA IS TELEKOMUNIKACIONOG DOMENA Kao što je prethodno rečeno, telekomunikacioni domen karakteriše izuzetna složenost. Mogu se identifikovati sledeće uzajamno ortogonalne dimenzije složenosti koje predstavljaju osnovne uzroke za raznolikost unutar telekomunikacionog domena:  Funkcionalni domeni – Horizontalni procesi prema NGOSS-eTOM  Oblasti integrisanih procesa – Vertikalni Sa-kraja-na-Kraj procesi prema NGOSS-eTOM  Tipovi (vrste) telekomunikacionih servisa koje konkretni operator nudi i koji su predmet automatizacije  Faze životnog ciklusa razvoja IS  Konkretni telekom operatori za koje se razvija IS. Višedimenzionalna složenost telekomunikacionog domena je ilustrovana na Slici 3.1.: Dimenzija 1: Funkcionalni domeni – Horizontalni procesi prema NGOSS-eTOM predstavljaju klasifikaciju telekomunikacionog domena prema funkcionalnim oblastima:  Upravljanje odnosima sa korisnikom – CRM (Proizvod)  Upravljanje operativom servisa (Servis) 55 … .. . Živo tn i ciklu s razvo ja IS Konkretni Telekom operatori DOBAVLJAČ RESURS SERVIS CRM IS P U N JE N JE ( R EA LI ZA C IJ A ) PSTN DOBAVLJAČ RESURS SERVIS CRMISP U N JEN JE (R EA LIZA C IJA ) IPTV DOBAVLJAČ RESURS SERVIS CRM O SI G U R A N JE PSTN DOBAVLJAČ RESURS SERVIS CRM O SIG U R A N JE IPTV DOBAVLJAČ RESURS SERVIS CRM FA K TU R IS A N JE ( B IL LI N G ) DOBAVLJAČ RESURS SERVIS CRMFA K TU R ISA N JE (B ILLIN G ) IPTV PSTN H o rizo n taln i p ro ce si (Fu n kcio n aln i d o m e n i) Vertikalni procesi (Procesi Sa-kraja-na-Kraj) Ti p se rv isa DOBAVLJAČ RESURS SERVIS CRM IS P U N JE N JE ( R EA LI ZA C IJ A ) PSTN DOBAVLJAČ RESURS SERVIS CRMISP U N JEN JE (R EA LIZA C IJA ) IPTV DOBAVLJAČ RESURS SERVIS CRM O SI G U R A N JE PSTN DOBAVLJAČ RESURS SERVIS CRM O SIG U R A N JE IPTV DOBAVLJAČ RESURS SERVIS CRM FA K TU R IS A N JE ( B IL LI N G ) DOBAVLJAČ RESURS SERVIS CRMFA K TU R ISA N JE (B ILLIN G ) IPTV PSTN DOBAVLJAČ RESURS SERVIS CRM IS P U N JE N JE ( R EA LI ZA C IJ A ) PSTN DOBAVLJAČ RESURS SERVIS CRMISP U N JEN JE (R EA LIZA C IJA ) IPTV DOBAVLJAČ RESURS SERVIS CRM O SI G U R A N JE PSTN DOBAVLJAČ RESURS SERVIS CRM O SIG U R A N JE IPTV DOBAVLJAČ RESURS SERVIS CRM FA K TU R IS A N JE ( B IL LI N G ) DOBAVLJAČ RESURS SERVIS CRMFA K TU R ISA N JE (B ILLIN G ) IPTV PSTN H o rizo n taln i p ro ce si (Fu n kcio n aln i d o m e n i) Vertikalni procesi (Procesi Sa-kraja-na-Kraj) Ti p se rv isa DOBAVLJAČ RESURS SERVIS CRM IS P U N JE N JE ( R EA LI ZA C IJ A ) PSTN DOBAVLJAČ RESURS SERVIS CRMISP U N JEN JE (R EA LIZA C IJA ) IPTV DOBAVLJAČ RESURS SERVIS CRM O SI G U R A N JE PSTN DOBAVLJAČ RESURS SERVIS CRM O SIG U R A N JE IPTV DOBAVLJAČ RESURS SERVIS CRM FA K TU R IS A N JE ( B IL LI N G ) DOBAVLJAČ RESURS SERVIS CRMFA K TU R ISA N JE (B ILLIN G ) IPTV PSTN Sp e cifikacija zah te va P ro je kto van je Operator A Operator B Slika 3.1. Pet dimenzija složenosti telekomunikacionog domena. 56  Upravljanje operativom resursa (Resurs)  Upravljanje odnosima sa Partnerima/Dobavljačima (Dobavljač) Dimenzija 2: Klase procesa Sa-kraja-na-Kraj – Vertikalni procesi prema NGOSS- eTOM predstavljaju klasifikaciju procesa koji integrišu horizontalne procese (ortogonalno seku funkcionalne domene).  Ispunjenje (realizacija)  Obezbeđenje (osiguranje)  Fakturisanje (Billing)  Itd. Dimenzija 3: Tip servisa. Kroz dimenziju 1, Funkcionalni domeni definisane su sve funkcionalne oblasti telekomunikacionog modela. Kroz dimenziju 2, Vertikalni procesi povezuju se funkcionalni poddomeni u procese Sa-kraja-na-Kraj. Ovakvi procesi predstavljaju krupnu biznis apstrakciju koja je nezavisna od Tipa servisa. Dimenzija 3 uključuje Tip servisa za funkcionalne oblasti i procese Sa-kraja-na-Kraj. Postoje sledeći tipovi telekomunikacionih servisa:  Širokopojasni servisi: Internet, IPTV, VoIP, ADSL, itd.  Servisi fiksne telefonije: PSTN, ISDN, zakupljeni vod, itd.  Servisi mobilne telefonije: Prepaid, Postpaid, Fiskalne kase, itd.  Servisi za zabavu: Igrice, itd. Dimenzija 4: Prethodne tri dimenzije sada treba dovesti u vezu sa Životnim ciklusom razvoja IS telekomunikacionog domena:  Specifikacija zahteva (Inženjerstvo korisničkih zahteva)  Projektovanje (dizajn )  Realizacija  Testiranje 57 Dimenzija 5: Prethodne četiri dimenzije telekomunikacionog domena čine takozvani domenski inženjering kojim se definiše kompletna familija softverskih proizvoda. Sada je potrebno omogućiti da se konfiguriše članovi familije a to su IS za konkretne telekom operatore. Kada se sagledaju sve dimenzije složenosti neophodno je definisati strategiju kretanja po dimenzijama. To se definiše kroz metodološki postupak razvoja IS koji daje odgovor na sledeća pitanja:  Kako se dekomponuje složeni domen kao što je domen telekomunikacija  Kako se obilaze poddomeni i šta znači prelazak sa jednog na drugi poddomen Sam redosled kretanja kroz poddomene nameće NGOSS tj. priroda telekomunikacionog domena, a mehanizam za višenivovsko konfigurisanje je tehnika kako da se pređe iz jedne tačke razvoja u drugu tačku odnosno iz jednog poddomena u drugi poddomen. 3.2. TEHNIKA ZA SAVLADAVANJE SLOŽENOSTI I POSTEPENU KONKRETIZACIJU TELEKOMUNIKACIONOG DOMENA Pristup razvoja IS preko Softverskih proizvodnih linija ima dobru tehniku za prikazivanje zajedničkih i različitih karakteristika u domenu, to su Modeli karakteristika (MK). Međutim nije moguće napraviti jedan ogroman Model karakteristika za ceo telekomunikacioni domen. Potrebno je postepeno dekomponovati domen i na različitim apstraktnim nivoima dekompozicije definisati više manjih MK kojima se može lakše upravljati. Višenivovsko konfigurisanje je tehnika za savlađivanje složenosti i postepenu konkretizaciju domena. Pored toga to je tehnika za obilazak domena i prelazak iz jednog poddomena u drugi. Tokom obilaska poddomena primenom tehnike Višenivovskog konfigurisanja, proizvode se postepeno po poddomenima manji bolje upravljivi Modeli karakteristika. 3.2.1. OSNOVNI MEHAN IZAM ZA VIŠENIVOVSKO KONFIGURISANJE Nije moguće unapred napraviti Model karakteristika za poddomen, jer takav MK može da bude zavisan od rezultata poddomena koji mu prethodi. Zato se u startu prave samo 58 početni, okvirni Modeli karakteristika (MK šabloni) za poddomen a onda kroz nivoe konfiguracije prave stvarni Modeli karakteristika, na osnovu početnog MK na nekom nivou i konfiguracije sa nivoa koji mu prethodi. Tako se uzima u obzir rezultat neke prethodne faze, odluka nekog drugog projektanta. Tehnika Višenivovsko konfigurisanje (Višenivovsko instanciranje) je softverska proizvoda linija (fabrika) za pravljenje Modela karakteristika. Na Slici 3.2. prikazan je osnovni mehanizam za Višenivovsko fazno konfigurisanje. Na Nivou N-1 definisan je Model karakteristika (MK). Za ovaj MK radi se ručno Konfiguracija (konfiguracija na Nivou N-1). Na Nivou N definisan je novi Model karakteristika koji je povezan sa Modelom karakteristika na Nivou N-1 preko oznaka (Anotacija). Na Nivou N izvršava se algoritam za automatsku specijalizaciju MK. Primenom Konfiguracije sa Nivoa N-1 na MK na Nivou N, automatski se generiše novi MK na Nivou N, koji je uži (specijalizovani) MK u odnosu na početni MK sa Nivoa N. Sada se za novi, automatski generisan MK na Nivou N pravi ručna Konfiguracija. Model Karakteristika Nivo N Model Karakteristika Nivo N-1 Konfiguracija Nivo N-1 Konfiguracija Nivo N Nivo N-1 Nivo N Osnovni mehanizam za višenivovsko konfigurisanje Označene karakteristike Specijalizovani Model Karakteristika Nivo N N > 0 Automatska specijalizacija Nivo N-1: Specifikacija (Zahtev) Nivo N: Realizacija Specifikacije za Nivo N-1 Slika 3.2. Osnovni mehanizam za višenivovsko konfigurisanje. Ovaj osnovni mehanizam za višenivovsko konfigurisanje predstavlja tehniku za obilazak dimenzija telekomunikacionog domena. Nivoi predstavljaju pojedine 59 poddomene a sam mehanizam način za prelazak sa poddomena na poddomen. Tom prilikom jedan poddomen daje svoje rezultate i specifikacije drugom poddomenu (konfiguracije), odnosno razvoj drugog poddomena zavisi od rezultata razvoja poddomena koji mu prethodi. Na ovaj način definiše se međuzavisnost i povezanost određenih poddomena. Kao što je na levoj strani Slike 3.2. dato Nivo N-1 predstavlja specifikaciju za Nivo N a Nivo N predstavlja Realizaciju nivoa N-1. Detaljniji opis mehanizma i algoritma za Automatsku specijalizaciju Modela karakteristika daje se u poglavlju četiri. Pored toga tu će se i detaljno ilustrovati funkcionisanje ovog mehanizma. U nastavku ovog poglavlja prikazuje se sistem višenivovskog konfigurisanje telekomunikacionog domena koji je zasnovan na prikazanom mehanizmu za višenivovsko konfigurisanje. 3.2.2 VIŠENIVOVSKO KONFIGURISANJE TELEKOMUNIKACIONOG DOMENA NGOSS okviri eTOM i SID predstavljeni osnov za definisanje šema za višenivovsko konfigurisanje telekomunikacionog domena. Na Slici 3.3. prikazana je osnovna šema telekomunikacionog domena za višenivovsko fazno konfigurisanje telekomunikacionog domena. Pravougaonici na šemi predstavljaju funkcionalne poddomene (klase poddomena) i označeni su istim bojama kao u eTOM i SID-u da bi se lakše u daljem detaljnom prikazu pratili. Horizontalni procesi na Slici 3.3. su preslikani iz eTOM okvira i ima ih ukupno četiri (četiri funkcionalne oblasti). Vertikalni eTOM procesi su modifikovani korišćenjem SID okvira tako da ih na slici ima ukupno šest. Između funkcionalnih poddomena definisane su zavisnosti koje mogu biti horizontalne, unutar horizontalnog procesa i vertikalne između poddomena različitih horizontalnih procesa. Ova slika sagledava prve dve dimenzije složenosti koje su još definisane u eTOM okviru a to je Horizontalna i Vertikalna klasifikacija procesa telekomunikacionog domena. 60 Horizontalna klasifikacija procesa telekomunikacionog domena obuhvata četiri klase horizontalnih procesa što u suštini predstavlja četiri velike funkcionalne oblasti:  Proizvod – Upravljanje odnosom sa korisnikom. Proizvod predstavlja pogled korisnika na Servis gde on vidi samo funkcionalnosti servisa (Customer Facing Service prema SID okviru).  Servis – Upravljanje operativom servisa. Servis predstavlja tehnički pogled na servis (Resource Facing Service prema SID okviru), odnosno servisi realizuju funkcionalnosti proizvoda.  Resurs – Upravljanje operativom resursa. Resurs predstavlja realizaciju servisa preko elemenata telekomunikacione mreže.  Dobavljač/Partner – Upravljanje odnosom sa Dobavljačem/Partnerom. Dobavljači/Partneri omogućavaju isporuku, montažu i održavanje opreme i na taj način funkcionisanje gornjih slojeva. Pored toga Dobavljač/Partner može da daje direktno svoje servise telekom operatoru. Tako se formiraju takozvani Cobranded servisi, zajednički servisi od strane više provajdera. Vertikalni procesi poređani kao na Slici 3.3. seku pojedine delove različitih funkcionalnih oblasti. Oni obuhvataju pojedine poddomene različitih funkcionalnih oblasti u celinu koja čini klasu procesa Sa-kraja-na-Kraj. Tako na primer klasa procesa Razvoj proizvoda se formira tako što: Specifikacija Proizvoda se realizuje preko Specifikacije Servisa, Specifikacija Servisa preko Specifikacije Resursa a Specifikacija Resursa preko Specifikacije Dobavljača/Partnera. Na Slici 3.3. definisane su sledeće klase vertikalnih procesa:  Razvoj proizvoda  Ispunjenje (Realizacija)  Obezbeđenje održavanja  Obezbeđenje kvaliteta  Obračun (Billing)  Obezbeđenje prihoda. 61 Specifikacija Proizvoda Specifikacija Servisa Specifikacija Resursa Specifikacija Proizvoda za nuđenje Konfiguracija i aktivacija Servisa (Dizajn Servisa) Provisioning Resursa Zahtev za realizaciju D/P Problemi Proizvoda Problemi na Servisu Problemi na Resursu Problemi na resursu za D/P Faktura za Proizvod Obračun za Servis Obračun za Resurs Prebijanje Obračuna sa D/P SLA za Proizvod Performanse Servisa Performanse Resursa Obezbeđenje kvaliteta resursa od D/P Uplata za Fakturu Uplata za Servis Uplata za Resurs (Prepaid) Uplate/Isplate D/P Specifikacija Resursa D/P (Ugovor sa D/P) VP Nivo 0 Razvoj proizvoda VP Nivo 1 Ispunjenje (Realizacija) VP Nivo 2 Obezbeđenje održavanja VP Nivo 3 Obezbeđenje kvaliteta VP Nivo 4 Obračun VP Nivo 5 Obezbeđenje prihoda HP Nivo 0 Upravljanje odnosom sa Korisnikom HP Nivo 1 Upravljanje operativom Servisa HP Nivo 2 Upravljanje operativom Resursa HP Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom N Faza konfigurisanja N = {0,1,2,3} N Faza konfigurisanja N = {0,1,2,3} N Faza konfigurisanja N = {0,1,2,3} N Faza konfigurisanja N = {0,1,2,3} N Faza konfigurisanja N = {0,1,2,3} N Faza konfigurisanja N = {0,1,2,3} N F az a ko n fi gu ri sa n ja N = { 0 ,1 ,. ., 5 } N F az a ko n fi gu ri sa n ja N = { 0 ,1 ,. ., 5 } N F az a ko n fi gu ri sa n ja N = { 0 ,1 ,. ., 5 } N F az a ko n fi gu ri sa n ja N = { 0 ,1 ,. ., 5 } Slika 3.3. Šema za višenivovsko fazno konfigurisanje za telekomunikacioni domen. 62 Očigledno da jedni isti poddomeni pripadaju i horizontalnim i vertikalnim procesima, odnosno nalaze se u preseku dvostruke klasifikacije. Slika 3.3. takođe pokazuje sveobuhvatan pogled na telekomunikacioni domen i zbog toga ima veliki značaj. Na Slici 3.3. prikazane su prve dve dimenzije složenosti telekomunikacionog domena njihove međusobne uslovljenosti i zavisnosti. Sada je moguće definisati uloge ovih dimenzija kao i redosled obilazaka poddomena a zatim na to primeniti tehniku višenivovskog konfigurisanja kojom se realizuje kretanje kroz poddomene. Horizontalni procesi i njihovi poddomeni predstavljaju funkcionalne oblasti čije poddomene treba prvo obići tako što se krene odozgo na dole po funkcionalnim oblastima. Unutar funkcionalne oblasti uvek se poddomeni obilaze sa leva na desno. To znači da prvo treba razviti rukotvorine za poddomene koji su u vezi proizvoda a zatim rukotvorine za poddomene u vezi servisa, pa onda resurs,a itd. Unutar poddomena vezanih za proizvod treba raditi razvoj u sledećem redosledu: Specifikacija proizvoda, Specifikacija proizvoda za nuđenje, Problemi proizvoda, SLA za proizvod, Faktura za proizvod, Uplata za fakturu, itd. Posle toga treba obilaziti vertikalne procese sa leva na desno: Razvoj proizvoda, Ispunjenje, Obezbeđenje održavanja, itd. Posle prethodne diskusije a na osnovu Slike 3.3. mogu da se definišu dva tipa šema za Višenivovsko fazno konfigurisanje koje treba da omoguće horizontalno i vertikalno kretanje kroz poddomene koristeći rezultate prethodnog domena za realizaciju domena koji sledi. To su šeme za:  Horizontalno Višenivovsko Fazno konfigurisanje. Ovih šema ima ukupno četiri onoliko koliko i horizontalnih procesa. Svaka šema ima od 0 do 5 nivoa i one će detaljno biti prikazane u poglavlju četiri. Suština ili glavni rezultat ovog horizontalnog višenivovskog faznog konfigurisanja su početni Modeli karakteristika za svaki poddomen (Početni MK su u stvari Šabloni MK). Ovi modeli kako prikazuje slika su horizontalno zavisni jedan od drugog i konstruišu se sa leva na desno (tako definisane i zavisnosti između poddomena). MK sa leve strane predstavlja uzor (pattern) za definisanje modela sa desne strane. Pored MK koji predstavljaju vodilju definišu se i drugi modeli po istom principu (UML šabloni). 63  Vertikalno Višenivovsko Fazno konfigurisanje se obavlja kroz šest šema, kojih ima onoliko koliko i vertikalnih procesa, od koji svaka ima od 0 do 3 nivoa konfigurisanja. Redosled njihovog definisanja i izvođenja je sa leva na desno (Slika ). Glavni rezultat izvršenja vertikalne višenivovske fazne konfiguracije je realizacija razvoja vertikalnih procesa kroz višenivovsku faznu transformaciju Modela karakteristika gde rezultat (konfiguracija) sa prethodnog nivoa predstavlja ulazne parametre za izradu modela karakteristika na donjem nivou. Na primer ako se posmatra šema za vertikalno višenivovsko konfigurisanje Razvoj proizvoda, MK Servisa se generiše na osnovu Konfiguracije proizvoda sa prethodnog nivoa. Modeli karakteristika nisu poznati unapred jer MK jednog poddomena zavisi od konfiguracije iz prethodnog poddomena. Tehnika višenivovskog konfigurisanja omogućava da se kroz horizontalno konfigurisanje MK definišu okvirno (definišu se šabloni MK) a da se zatim kroz vertikalno konfigurisanje definišu prave instance MK. Detaljni prikaz šema, modela, primera konfigurisanja daje se u poglavlju četiri. Sada kada su sagledane sve dimenzije složenosti telekomunikacionog domena (prve dve su i detaljnije razjašnjene), kada je objašnjena tehnika za obilazak domena i redosled obilaska prve dve dimenzije, moguće je definisati Okvir softverske proizvodne linije za izgradnju IS Telekom operatora koji će obuhvatiti i ostale tri dimenzije. 3.3. OKVIR SOFTVERSKE PROIZVODNE LINIJE ZA TELEKOMUNIKACIONI DOMEN Metodološki pristup za razvoj IS telekom operatora bazira se na specifičnoj softverskoj proizvodnoj liniji (SPL). Okvir softverske proizvodne linije za telekomunikacioni domen prikazan je na Slici 3.4. i obuhvata svih pet dimenzija složenosti izgradnje IS telekomunikacionog domena. Ceo telekomunikacioni domen je definisan je kao jedna softverska familija proizvoda koja obuhvata: sve funkcionalne poddomene, sve klase procesa Sa-kraja-na-Kraj, sve tipove ICT servisa, sve faze razvoja u SPL, sve IS telekom operatora. Članovi softverske familije proizvoda su IS konkretnih telekomunikacionih kompanija koji mogu da se konfigurišu iz domenskih rukotvorina. SPL telekomunikacionog domena sadrži dve celine: 64  Domenski inženjering  Aplikacioni inženjering Inženjerstvo domenskih zahteva Dizajn domena Realizacija domena Testiranje domena Zahtevi Arhitektura Komponente Testovi Inženjerstvo aplikacionih zahteva Dizajn aplikacije Realizacija aplikacije Testiranje aplikacije Zahtevi Arhitektura Komponente Testovi Horizontalni procesi (Funkcionalni domeni) Informacioni Sistem Telekom oparatora 1 D O M E N S K I I N Ž E N J E R I N G A P L I K A C I O N I I N Ž E N J E R I N G Vertikalni procesi (Sa-kraja-na-Kraj) Horizontalni procesi (Funkcionalni domeni) za Tip servisa 1..S Vertikalni procesi (Funkcionalni domeni) za Tip servisa 1..S Informacioni Sistem Telekom oparatora 2 Informacioni Sistem Telekom oparatora N Opšti Domenski inženjering za telekomunikacioni domen Domenski inženjering za Tip servisa Slika 3.4. Okvir softverske proizvodne linije za telekomunikacioni domen na prvom, najvišem nivou dekompozicije. 65 Međutim softverska proizvodna linija telekomunikacionog domena nije obična SPL, jer softverska familija proizvoda za ovaj domene je enormno složena i zbog toga su potrebna dva nivoa domenskog inženjeringa: Opšti domenski inženjering za telekomunikacioni domen i Domenski inženjering telekomunikacionog domena za Tip servisa. To znači da ne može da postoji domenski inženjering za domenski inženjering. Slika 3.4. prikazuje strukturu SPL okvira na prvom nivou dekompozicije. Redosled obilaska dimenzija prikazanih na Slici 3.4. je sledeći: 1. Prvo se realizuje Opšti domenski inženjering za telekomunikacioni domen. Ovu fazu rade eksperti na nivou NGOSS standarda. Ona se radi relativno retko, kada se standard dopunjuje i menja, možda jednom u deceniji ili ređe. Ova faza obuhvata sledeće korake:  Specificiraju se i definišu Funkcionalni domeni (Horizontalni procesi) nezavisno od tipa servisa. Glavni rezultat ovog koraka su šeme za horizontalno višenivovsko fazno konfigurisanje.  Razvijaju se klase procesa Sa-kraja-na-Kraj (Vertikalni procesi) nezavisno od tipa servisa. Glavni rezultat ovog koraka su šeme za vertikalno višenivovsko fazno konfigurisanje klasa vertikalnih procesa.  I Funkcionalni domeni i Vertikalne klase procese se specificiraju razvijaju i izgrađuju po životnom ciklusu razvoja softverske proizvodne linije: Inženjerstvo domenskih zahteva, Dizajn domena, Realizacija domena, Testiranje domena. 2. Zatim se realizuje Domenski inženjering za Tip servisa. Ovu fazu rade eksperti poznavaoci Proizvoda (Product Life Cycle - PLM eksperti). Ona se obavlja mnogo češće nego što je to kod opšteg domenskog inženjeringa za telekomunikacioni domen. Radi se jednom godišnje ili u dve tri godine kada se uvodi novi tip (klasa) servisa. Domenski inženjering za tip servisa radi se onoliko puta koliko ima tipova telekomunikacionih servisa. Koraci domenskog inženjeringa za tip servisa su:  Horizontalni procesi za Tip servisa se razvijaju u skladu sa rukotvorinama horizontalnih procesa (artifaktima) definisanim u opštem domenskom inženjeringu za telekomunikacioni domen. Ovde se koriste šeme za horizontalno 66 višenivovsko konfigurisanje da bi se generisali Modeli karakteristika za tip servisa. Dakle glavni rezultat ovog koraka su MK i drugi šabloni modela za tip servisa. Šeme za horizontalno višenivovsko fazno konfigurisanje koje su pre toga predstavljale samo ljušture sada su kompletirane sa modelima za tip servisa.  Vertikalni procesi za Tip servisa se razvijaju u skladu sa rukotvorinama vertikalnih procesa (artifaktima) definisanim u opštem domenskom inženjeringu. Ovde se koriste šeme za vertikalno višenivovsko konfigurisanje da bi se kroz transformaciju modela realizovale klase vertikalnih procesa za tip servisa. Dakle glavni rezultat ovog koraka su vertikalni procesi za tip servisa. I šeme za vertikalno višenivovsko fazno konfigurisanje koje su pre toga predstavljale samo ljušture sada su kompletirane sa modelima za tip servisa i pravilima za njihovu transformaciju (anotacije modela).  I Funkcionalni domeni i Vertikalne klase procesa za Tip servisa se specificiraju razvijaju i izgrađuju po životnom ciklusu razvoja softverske proizvodne linije: Inženjerstvo domenskih zahteva, Dizajn domena, Realizacija domena, Testiranje domena. 3. Na kraju se radi Aplikacioni inženjering. Ovu fazu rade eksperti za specifikaciju i izgradnju informacionih sistema. ona se obavlja relativno frekventno, tj. kada god se javlja potreba nekog telekom operatora za IS. Sinonim za Telekom operatora je Tip servisa koje operator nudi korisnicima, tako da glavni ulazni zahtev za IS telekom operatora je „Generiši IS za Tip servisa“. Koraci u ovoj fazi su:  Konfiguriše se zahtev Konkretnog telekom operatora za razvoj IS za konkretni Tip servisa i na osnovu toga i SPL rukotvorina domenskog inženjeringa za tip servisa generiše se IS za konkretnog telekom operatora: Modeli podataka, Modeli aplikacija, Modeli procesa. Moguće je na ovaj način kroz proces kastomizacije domenskih rukotvorina telekomunikacionog domena, generisati N IS za N konkretnih telekom operatora.  Izgradnja IS konkretnih telekom operatora se specificiraju razvijaju i izgrađuju po životnom ciklusu razvoja softverske proizvodne linije za aplikacioni 67 inženjering: Inženjerstvo aplikacionih zahteva, Dizajn aplikacije, Realizacija aplikacije, Testiranje aplikacije. U nastavku sledi detaljnije objašnjenje metodološkog okvira za razvoj IS telekom operatora na sledećem nižem, drugom nivou dekompozicije. Prvo se daje detaljnije Domenski inženjering a zatim i Aplikacioni inženjering telekomunikacionog domena. 3.4. SPL OKVIR ZA DOMENSKI INŽENJERING TELEKOMUNIKACIONOG DOMENA Okvir softverske proizvodne linije za domenski inženjering telekomunikacionog domena se sastoji iz dva dela: Opšti domenski inženjering telekomunikacionog domena i Domenski inženjering za tip servisa. 3.4.1. OPŠTI DOMENSKI INŽENJERING TELEKOMUNIKACIONOG DOMENA Na Slici 3.5. prikazuje se drugi nivo dekompozicije Opšteg domenskog inženjeringa telekomunikacionog domena. Na ovom nivou postoji pet koraka koji se obavljaju sekvencijalno u skladu sa SPL životnim ciklusom razvoja. Ovi koraci su dobijeni primenom prethodno definisanog mehanizma za višenivovsko fazno konfigurisanje i NGOSS okvira. Koraci opšteg domenskog inženjeringa telekomunikacionog domena na ovom nivou su:  Definisanje šeme za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTK). Korak pripada fazi Inženjerstva domenskih zahteva. Glavni rezultat je osnovna polazna šema za Višenivovsko fazno Konfigurisanje Telekomunikacionog Domena (VFKTD), koja je dobijena kombinovanjem NGOSS eTOM i SID okvira i mehanizma za Višenivovsko Fazno Konfigurisanje. Obe ove stvari su prethodno detaljno objašnjene.  Definisanje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK). Korak pripada fazi Dizajna domena. Glavni rezultat koraka su šeme i mehanizmi HVFK sistema, koji su definisani na osnovu polazne šeme za Višenivovsko fazno Konfigurisanje Telekomunikacionog Domena (VFKTD). 68  Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK). I ovaj korak pripada fazi Dizajna domena. Glavni rezultat koraka su šeme i mehanizmi VVFK sistema, koji su definisani na osnovu polazne šeme za Višenivovsko fazno Konfigurisanje Telekomunikacionog Domena (VFKTD). NGOSS – SID Definisanje šeme za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTD) Definisanje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) VFKTD šema telekomunikacionog domena Definisanje sistema za VertikalnoVišenivovsko Fazno Konfigurisanje (VVFK) Definisanje sistema za Generisanje IS NGOSS – eTOM NGOSS – SID Šeme i mehanizmi HVFK sistema Šeme i mehanizmi VVFK sistema In že n je rs tv o d o m en sk ih z ah te va Šeme I mehanizmi za generisanje IS O P ŠT I D O M EN SK I I N ŽE N JE R IN G D iz aj n d o m en a R ea liz ac ija d o m en a Testiranje sistema Te st ir an je d o m en a Testovi HVFK, VVFK, IS Slika 3.5. Opšti domenski inženjering telekomunikacionog domena na drugom nivou dekompozicije.  Definisanje sistema za Generisanje IS. Korak pripada fazi Realizacije domena. Glavni rezultat koraka su šeme i mehanizmi sistema za generisanje IS, koji su definisani na osnovu VVFK sistema i NGOSS SID UML modela. 69  Testiranje sistema. Korak pripada fazi Testiranje domena. Glavni rezultat koraka su testovi za HVFK i VVFK sisteme kao i testovi za IS. 3.4.2. DOMENSKI INŽENJERING TELEKOMUNIKACIONOG DOMENA ZA TIP SERVISA Na Slici 3.6. prikazuje se drugi nivo dekompozicije Domenskog inženjeringa telekomunikacionog domena za tip servisa. Na ovom nivou postoji pet koraka koji se obavljaju sekvencijalno u skladu sa SPL životnim ciklusom razvoja. Ovi koraci su dobijeni na osnovu koraka iz Opšteg domenskog inženjeringa a primenom na tip servisa. Koraci ovog domenskog inženjeringa su:  Uvođenje novog Tipa servisa (PLM – Obuhvat za Tip servisa). Korak pripada fazi Inženjerstva domenskih zahteva. Glavni rezultat su Šeme HVFK sistema za Tip servisa koje su selektovane iz opšteg domena Šeme i mehanizmi HVFK sistema.  Definisanje šablona modela u sistemu za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) za Tip Servisa. Korak pripada fazi Dizajna domena. Glavni rezultat koraka su Modeli Karakteristika i ostali šabloni za funkcionalne poddomene za Tip servisa, koji su definisani na osnovu selektovanih Šema HVFK sistema za Tip servisa i Telekomunikacionog Informacionog Sistema (TIS).  Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) za Tip Servisa. Korak pripada fazi Dizajna domena. Glavni rezultat koraka su Šeme VVFK sistema za Tip servisa sa anotiranim karakteristikama modela, koji su definisani na osnovu Modeli Karakteristika za funkcionalne poddomene za Tip servisa i Šema i mehanizma VVFK sistema.  Definisanje sistema za Generisanje modela za Tip Servisa. Korak pripada fazi Realizacije domena. Glavni rezultat koraka su Šeme VVFK sistema za generisanje modela za Tip servisa i Šabloni UML modela, koji su definisani na osnovu Šeme i mehanizama za generisanje IS i Šeme VVFK sistema za Tip servisa (anotacije karakteristika). 70  Testiranje sistema za Tip Servisa. Korak pripada fazi Testiranje domena. Glavni rezultat koraka su testovi za HVFK i VVFK sisteme kao i testovi za IS šeme. Šeme VVFK sistema za generisanje IS za Tip servisa Modeli Karakteristika za funkcionalne poddomene za Tip servisa TIS Definisanje sistema za Generisanje IS za Tip Servisa Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) za Tip Servisa Definisanje Modela u sistemu za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) za Tip Servisa D O M EN IN ŽE N JE R IN G Z A T IP S ER V IS A Šabloni UML modela i koda Tip servisa Uvođenje novog Tipa servisa (PLM – Obuhvat za Tip servisa) Šeme VVFK sistema za Tip servisa (anotacije karakteristika) In že n je rs tv o d o m en sk ih z ah te va D iz aj n d o m en a R ea liz ac ija d o m en a Te st ir an je d o m en a Testiranje sistema za Tip Servisa Testovi HVFK, VVFK, Modela Šeme i mehanizmi HVFK sistema Šeme i mehanizmi VVFK sistema Šeme HVFK sistema za Tip servisa Šeme i mehanizmi za generisanje IS Slika 3.6. Domenski inženjering za Tip servisa na drugom nivou dekompozicije. 3.4.3. RUKOTVORINE DOMENSKOG INŽENJERINGA ZA TELEKOMUNIKACIONI DOMEN Rukotvorine Domenskog inženjeringa za telekomunikacioni domen su: Zahtevi, Arhitektura, Komponente, Testovi su prikazane na Slici 3.7. Opšti domenski inženjering telekomunikacionog domena generiše sledeće rukotvorine:  Kroz inženjerstvo domenskih zahteva generišu se sledeći Zahtevi: 71 o Osnovna šema za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTD)  Kroz dizajn domena generiše se sledeća Arhitektura: o Šeme za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK), o Šeme za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK), o Osnovni VFK mehanizmi za transformaciju – generisanje modela  Kroz realizaciju domena generišu se sledeće Komponente: o Šeme za Generisanje Modela i koda (GM), o Osnovni mehanizmi za generisanje modela i koda  Kroz testiranje domena generišu se sledeći Testovi: o Testiranje HVFK, o Testiranje VVFK, o Testiranje IS Domenski inženjering telekomunikacionog domena za tip servisa se radi za svaki tip ICT servisa koji se pojavi. Tako na primer za IPTV servis generiše sledeće rukotvorine:  Kroz inženjerstvo domenskih zahteva generišu se sledeći Zahtevi: o Šeme HVFK sistema za IPTV  Kroz dizajn domena generiše se sledeća Arhitektura: o Modeli Karakteristika za funkcionalne poddomene za IPTV o Šeme VVFK sistema za IPTV (anotacije karakteristika)  Kroz realizaciju domena generišu se sledeće Komponente: o Šeme VVFK sistema za generisanje modela za IPTV o Šabloni UML modela za IPTV  Kroz testiranje domena generišu se sledeći Testovi: o Testovi HVFK, VVFK, Modela za IPTV 72 Opšti Domenski inženjering telekomunikacionog domena Domenski inženjering za Tip servisa Inženjerstvo domenskih zahteva Dizajn domena Realizacija domena Testiranje domena Zahtevi Arhitektura Komponente Testovi D O M E N S K I I N Ž E N J E R I N G Osnovna šema za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTD) Šeme za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) Šeme za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) Šeme za Generisanje IS Modeli Karakteristika za funkcionalne poddomene za IPTV Šabloni UML modela i koda za IPTV Testovi HVFK, VVFK, Modela za IPTV Osnovni VFK mehanizmi za transformaciju – generisanje Modela i koda Šeme HVFK sistema za IPTV Osnovni mehanizmi za generisanje IS Testiranje HVFK Testiranje VVFK Testiranje IS Šeme VVFK sistema za IPTV (anotacije karakteristika) Šeme VVFK sistema za IS za IPTV Modeli Karakteristika za funkcionalne poddomene za ... Temlejti UML modela za ... Testovi HVFK, VVFK, Modela za ... Šeme HVFK sistema za ... Šeme VVFK sistema za ... (anotacije karakteristika) Šeme VVFK sistema za generisanje modela za ... Slika 3.7. Softverske rukotvorine SPL za izgradnju IS Telekom operatora – domenski inženjering 73 3.5. SPL OKVIR ZA APLIKACIONI INŽENJERING TELEKOMUNIKACIONOG DOMENA Okvir softverske proizvodne linije za Aplikacioni inženjering definiše postupak konfigurisanja i tehniku realizacije IS konkretnog telekom operatora. Tom prilikom se konfigurišu modeli karakteristika i šeme domenskog inženjeringa za tip servisa tako da se dobija skup rukotvorina neophodnih za generisanje člana familije tj. IS za konkretnog operatora. U nastavku se daje dekompozicija aplikacionog inženjeringa na nivou dva kao i rukotvorine koje nastaju realizacijom aplikacionog inženjerstva. 3.5.1. APLIKACIONI INŽENJERING TELEKOMUN IKACIONOG DOMENA Na Slici 3.8. prikazuje se drugi nivo dekompozicije Aplikacionog inženjeringa telekomunikacionog domena. Na ovom nivou postoji četiri koraka koji se obavljaju sekvencijalno u skladu sa SPL životnim ciklusom razvoja. Ovi koraci su dobijeni primenom prethodno definisanog mehanizma za višenivovsko fazno konfigurisanje. Koraci aplikacionog inženjeringa na ovom nivou su:  Konfigurisanje zahteva IS konkretnog Telekom operatora (Obuhvat IS). Korak pripada fazi Inženjerstva aplikacionih zahteva. Glavni rezultati su: Šeme VVFK sistema IS konkretnog telekom operatora i Konfiguracija zahteva IS konkretnog operatora (Obuhvat), dobijeni iz Modela Karakteristika Telekomunikacionog domena za Tip servisa.  Realizacija VVFK IS konkretnog Telekom operatora. Korak pripada fazi Dizajn aplikacija. Glavni rezultati su: Konfiguracije MK iz VVFK šeme i Radni nalog za generisanje modela, dobijeni na osnovu Konfiguracija zahteva IS konkretnog operatora (Obuhvat) i Šema VVFK sistema IS konkretnog telekom operatora.  Generisanje IS konkretnog Telekom operatora. Korak pripada fazi Realizacija aplikacije. Glavni rezultati su: Modeli podataka, Modeli Aplikacija, Modeli procesa, dobijeni na osnovu Konfiguracije MK iz VVFK šeme i Radnog naloga za generisanje modela. Pored modela podrazumeva se da oni treba da se 74 transformišu u izvršni kod. Sama ova transformacija je već definisana u mnogim radovima pa u ovoj tezi se nije mnogo bavilo tim problemom. Na primer postoji dosta alata za generisanje koda iz UML modela dijagrama klasa ili definisanje XPDL koda iz modela procesa itd.  Testiranje IS konkretnog Telekom operatora. Korak pripada fazi Testiranje aplikacije. Glavni rezultati su: Testovi IS, dobijeni na osnovu: Modela podataka, Modela Aplikacija, Modela procesa. Šeme VVFK sistema IS konkretnog telekom operatora Generisanje IS konkretnog Telekom operatora Konfigurisanje zahteva IS konkretnog Telekom operatora (Obuhvat IS) A P LI K A C IO N I I N ŽE N JE R IN G Model Karakteristika Telekomunikacionog domena za Tip servisa Konfiguracija zahteva IS konkretnog operatora (Obuhvat) Tip servisa In že n je rs tv o ap lik ac io n ih z ah te va D iz aj n a p lik ac ije R ea liz ac ija a p lik ac ije Te st ir an je a p lik ac ije Testiranje IS konkretnog Telekom operatora Konfigurisanje šema za VVFK IS konkretnog Telekom operatora Konfiguracije MK iz VVFK šemeRadni nalog za generisanje modela Modeli podataka Modeli Aplikacija Modeli procesa Testovi IS Slika 3.8. Aplikacioni inženjering na drugom nivou dekompozicije. 3.5.2. RUKOTVORINE APLIKACIONOG INŽENJERINGA ZA TELEKOMUNIKACIONI DOMEN Rukotvorine Aplikacionog inženjeringa za telekomunikacioni domen su (Slika 3.9.): Zahtevi, Arhitektura, Komponente, Testovi. 75 Inženjerstvo aplikacionih zahteva Dizajn aplikacije Realizacija aplikacije Testiranje aplikacije Zahtevi Arhitektura Komponente Testovi Konfiguracija zahteva IS konkretnog operatora (Obuhvat) Šeme VVFK sistema IS konkretnog telekom operatora Modeli podataka Modeli Aplikacija Modeli procesa A P L I K A C I O N I I N Ž E N J E R I N G Testovi ISRadni nalog za generisanje modela Konfiguracije MK iz VVFK šeme Konfiguracija zahteva IS1 konkretnog operatora (Obuhvat) za IPTV servis Šeme VVFK sistema IS1 konkretnog telekom operatora Modeli podataka IS1 Modeli Aplikacija IS1 Modeli procesa IS1 Testovi IS1Radni nalog za generisanje modela za IS1 Konfiguracije MK iz VVFK šeme za IS1 Konfiguracija zahteva ISk konkretnog operatora (Obuhvat) za...servis Šeme VVFK sistema ISk konkretnog telekom operatora Modeli podataka ISk Modeli Aplikacija ISk Modeli procesa ISk Testovi ISkRadni nalog za generisanje modela za ISk Konfiguracije MK iz VVFK šeme za ISk Slika 3.9. Softverske rukotvorine SPL za izgradnju IS Telekom operatora – aplikacioni inženjering, drugi nivo dekompozicije 76 Aplikacioni inženjering se uvek radi iz Domenskog inženjeringa telekomunikacionog domena za tip servisa:  Kroz inženjerstvo domenskih zahteva generišu se sledeći Zahtevi: o Konfiguracija zahteva IS konkretnog operatora (Obuhvat)  Kroz dizajn domena generiše se sledeća Arhitektura: o Šeme VVFK sistema IS konkretnog telekom operatora o Radni nalog za generisanje modela o Konfiguracije MK iz VVFK šeme  Kroz realizaciju domena generišu se sledeće Komponente: o Modeli podataka o Modeli Aplikacija o Modeli procesa o Modeli koda o Itd.  Kroz testiranje domena generišu se sledeći Testovi: o Testovi IS. 77 4. DETALJNI OPIS METODOLOŠKOG PRISTUPA ZA IZGRADNJU IS TELEKOM OPERATORA Metodološki pristup za izgradnju IS telekom operatora bazira se na specifičnoj SPL koja obuhvata:  Opšti domenski inženjering telekomunikacionog domena  Domenski inženjering telekomunikacionog domena za Tip servisa  Aplikacioni inženjering telekomunikacionog domena U prethodnom poglavlju su definisani samo okviri metodološkog pristupa kroz dva nivoa dekompozicije. U ovom poglavlju, u nastavku daje se detaljni opis celokupnog metodološkog pristupa. 4.1. DETALJNI OPIS OPŠTEG DOMENSKOG INŽENJERINGA TELEKOMUNIKACIONOG DOMENA Kao što je prethodno već definisano osnovni koraci opšteg domenskog inženjeringa za telekomunikacioni domen su (Slika 4.1.):  Definisanje šeme za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTK).  Definisanje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK).  Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK).  Definisanje sistema za Generisanje Modela (GM).  Testiranje sistema. Prvi korak pristupa Definisanje šeme za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTK), je već u prethodnom poglavlju detaljno objašnjen, pa će se u nastavku detaljno opisati preostala četiri koraka. 78 4.1.1. DEFINISANJE SISTEMA ZA HORIZONTALNO VIŠENIVOVSKO FAZNO KONFIGURISANJE (HVFK) TELEKOMUNIKACIONOG DOMENA Sistem za horizontalno višenivovsko fazno konfigurisanje (HVFK) ima zadatak da kontrolisano (obezbeđuje poštovanje horizontalnih međuzavisnosti poddomena) i sveobuhvatno (obuhvata sve poddomene svih funkcionalnih oblasti) definiše sve početne Modele karakteristika po funkcionalnim oblastima telekomunikacionog domena. Na Slici 4.1. su definisani osnovni koraci HVFK sistema:  Definisanje osnovnog mehanizma HVFK za kreiranje Modela karakteristika. To je u suštini specijalni slučaj osnovnog mehanizma prikazanog u poglavlju tri, koji omogućava da se jednom izrađena Konfiguracija ponovo transformiše u Model karakteristika.  Definisanje sistema za HVFK kreiranje modela karakteristika za funkcionalni domen Upravljanje odnosom sa korisnikom. Sistem se realizuje preko Šeme HVFK za poddomen Upravljanje odnosom sa korisnikom.  Definisanje sistema za HVFK kreiranje modela karakteristika za funkcionalni domen Upravljanje operativom servisa. Sistem se realizuje preko Šeme HVFK za poddomen Upravljanje operativom servisa.  Definisanje sistema za HVFK kreiranje modela karakteristika za funkcionalni domen Upravljanje operativom resursa. Sistem se realizuje preko Šeme HVFK za poddomen Upravljanje operativom resursa.  Definisanje sistema za HVFK kreiranje modela karakteristika za funkcionalni domen Upravljanje odnosom sa Dobavljačem/Partnerom. Sistem se realizuje preko Šeme HVFK za poddomen Upravljanje odnosom sa Dobavljačem/Partnerom. Sistem za Horizontalno Višenivovsko Fazno Konfigurisanje se realizuje pomoću četiri HVFK šeme (šema ima onoliko koliko i horizontalnih procesa). Svaka šema ima od 0 do 5 nivoa. Suština ili glavni rezultat Sistema za horizontalno višenivovsko fazno konfigurisanje su početni Modeli karakteristika za svaki poddomen. Ovi modeli su horizontalno zavisni jedan od drugog (Slika poglavlje 3) i konstruišu se sa leva na desno (tako definisane i zavisnosti između poddomena). MK sa leve strane predstavlja uzor 79 In že n je rs tv o d o m en sk ih z ah te va O P ŠT I D O M EN SK I I N ŽE N JE R IN G D iz aj n d o m en a R ea liz ac ija d o m en a Te st ir an je d o m en a Definisanje sistema za HVFK kreiranje modela karakteristika za poddomen Upravljanje odnosom sa korisnikom Definisanje sistema za HVFK kreiranje modela karakteristika za poddomen Upravljanje operativom servisa Definisanje sistema za HVFK kreiranje modela karakteristika za poddomen Upravljanje operativom resursa Definisanje sistema za HVFK kreiranje modela karakteristika za poddomen Upravljanje odnosom sa Dobavljačem/Partnerom Definisanje osnovnog mehanizma HVFK za kreiranje Modela karakteristika Osnovni HVFK mehanizam Šema HVFK za poddomen Upravljanje odnosom sa korisnikom Šema HVFK za poddomen Upravljanje operativom servisa Šema HVFK za poddomen Upravljanje operativom resursa Šema HVFK za poddomen Upravljanje odnosom sa Dobavljačem/Partnerom NGOSS – SID Definisanje šeme za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTD) Definisanje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) VFKTD šema telekomunikacionog domena Definisanje sistema za VertikalnoVišenivovsko Fazno Konfigurisanje (VVFK) Definisanje sistema za Generisanje IS NGOSS – eTOM NGOSS – SID Šeme i mehanizmi HVFK sistema Šeme i mehanizmi VVFK sistema Šeme I mehanizmi za generisanje IS Testiranje sistema Testovi HVFK, VVFK, IS Slika 4.1. Opšti domenski inženjering – Definisanje HVFK sistema (treći nivo dekompozicije). 80 (pattern) za definisanje modela sa desne strane. Pored MK koji predstavljaju vodilju definišu se i svi neophodni šabloni modela: Šabloni modela podataka, Šabloni ponašanja (aplikacije i procesi), itd. 4.1.1.1. OSNOVI MEHANIZAM ZA KREIRANJE MODELA KARAKTERISTIKA IZ KONFIGURACIJE Na Slici 4.2. prikazan je Mehanizam koji omogućava generisanje Modela karakteristika na osnovu njegove Konfiguracije. Ovo je Specijalni oblik osnovnog mehanizma prikazan u poglavlju tri. Model Karakteristika Sa Niva N-1 Model Karakteristika Nivo N-1 Konfiguracija Nivo N-1 Model Karakteristika Nivo N Nivo N-1 Nivo N Osnovni mehanizam za višenivovsko Kreiranje MK Označene karakteristike Specijalizovani Model Karakteristika Nivo N N > 0 Automatska specijalizacija Ručna dorada MK Slika 4.2. Osnovni mehanizam za višenivovsko kreiranje Modela karakteristika iz njegove konfiguracije. Na nivou N-1 (N>0) definiše se MK (nivo N-1) na osnovu koga se manuelno pravi Konfiguracija (nivo N-1). Na nivou N definiše se MK koji je isti kao MK na nivou N-1 (zbog ovoga je ovaj mehanizam specijalna varijanta osnovnog mehanizma iz poglavlja 3). Karakteristike MK sa oba nivoa su međusobno označene (anotirane). Na osnovu: Konfiguracije sa nivoa N-1, MK na nivou N, Označenih karakteristika, Koraka specijalizacije, Algoritam za automatsku specijalizaciju generiše novi Specijalizovani MK na nivou N. 81 Takav Specijalizovani MK, predstavlja uzor za izradu novog MK. On se dorađuje ručno nakon čega se dobija rezultujući Model karakteristika na Nivou N. Početni MK je opšti Uzor koji je varijabilan (familija uzora) i kroz proces konfigurisanja se dobije Novi Uzor sužen skrojen za konkretnu potrebu. Kada se ovako definisan mehanizam primeni više puta uzastopno kroz međusobno zavisne pododmene horizontalnih procesa (funkcionalnih oblasti), dobijaju se Šeme za horizontalno višenivovsko fazno konfigurisanje. 4.1.1.2. DEFINISANJE SISTEMA ZA HVFK KREIRANJE MK ZA FUNKCIONALNI DOMEN UPRAVLJANJE ODNOSOM SA KORISNIKOM Na Slici 4.3. se prikazuju osnovni poddomeni funkcionalne oblasti Upravljanje odnosom sa korisnikom. Na Slici su jasno date zavisnosti između poddomena koje su sa leva na desno:  Specifikacija proizvoda je početni poddomen i od njega su zavisni poddomeni Specifikacija proizvoda za nuđenje i Problemi proizvoda. Specifikacija Proizvoda Specifikacija Proizvoda za nuđenje Problemi Proizvoda Faktura za Proizvod SLA za Proizvod Uplata za Fakturu Razvoj proizvoda Ispunjenje (Realizacija) Obezbeđenje održavanja Obezbeđenje kvaliteta Obračun Obezbeđenje prihoda Slika 4.3. Funkcionalna oblast Upravljanje odnosom sa korisnikom - poddomeni.  Specifikacija proizvoda za nuđenje utiče na definisanje poddomena SLA za proizvod i Faktura za proizvod.  Faktura za proizvod utiče na poddomen Uplata za fakturu. Slika 4.3. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za HVFK kreiranje modela karakteristika za poddomen Upravljanje odnosom sa korisnikom. Istovremeno na slici se vide i nazivi vertikalnih procesa kojima poddomeni pripadaju. Šema se dobija kada se mehanizam za kreiranje Modela karakteristika iz konfiguracija primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar funkcionalnog domena. 82 Na Slici 4.4. prikazana je Šema za kreiranje modela karakteristika za oblast Upravljanje odnosom sa korisnikom, primenom tehnike za višenivovsko fazno konfigurisanje. Šema ima šest nivoa konfigurisanja (od 0 do 5). Nivoe čine vertikalni procesi: 0 – Razvoj proizvoda, 1 - Ispunjenje (Realizacija), 2 – Obezbeđenje održavanja, 3 – Obezbeđenje kvaliteta, 4 – Obračun, 5 – Obezbeđenje prihoda. Višenivovsko fazno konfigurisanje po ovoj šemi odvija se sledećim redosledom: Ručno kreiranje MK Specifikacija proizvoda Na Nivou 0 - Razvoj proizvoda, kreira se ručno MK Specifikacija Proizvoda. Zatim se ručno kreira Konfiguracija Specifikacije Proizvoda. Kreiranje MK Specifikacija proizvoda za nuđenje Na Nivou 1 - Ispunjenje (Realizacija), postavlja se početni MK Specifikacija Proizvoda. Automatskom specijalizacijom MK Specifikacija Proizvoda koja se radi primenom konfiguracije Specifikacije Proizvoda dobija se početni MK Specifikacija proizvoda za nuđenje. Njegovom ručnom doradom dobija se MK Specifikacija proizvoda za nuđenje. Kreiranje MK Problemi proizvoda Na Nivou 2 – Obezbeđenje održavanja, postavlja se početni MK Specifikacija Proizvoda. Automatskom specijalizacijom MK Specifikacija Proizvoda koja se radi primenom konfiguracije Specifikacije Proizvoda dobija se početni MK Problemi proizvoda. Njegovom ručnom doradom dobija se MK Problemi proizvoda. Kreiranje dve konfiguracije MK Proizvod za nuđenje Na Nivou 1 - Ispunjenje (Realizacija), iz MK Specifikacija proizvoda za nuđenje kreiraju se dve različite konfiguracije: Konfiguracija 1 Specifikacija proizvoda za nuđenje i Konfiguracija 2 Specifikacija proizvoda za nuđenje. Kreiranje MK SLA za proizvod Na Nivou 3 – Obezbeđenje kvaliteta, postavlja se početni MK Specifikacija proizvoda za nuđenje. Automatskom specijalizacijom MK Specifikacija proizvoda za nuđenje koja se radi primenom konfiguracije 1 Specifikacija proizvoda za nuđenje dobija se početni MK SLA za proizvod. Njegovom ručnom doradom dobija se MK SLA za proizvod. 83 MK Specifikacija Proizvoda Faza 0 Faza 1 Faza 2 Nivo 0 Razvoj proizvoda Nivo 1 Ispunjenje (Realizacija) Nivo 2 Obezbeđenje održavanja Nivo 3 Obezbeđenje kvaliteta Nivo 4 Obračun Nivo 5 Obezbeđenje prihoda MK Problemi Proizvoda MK SLA za Proizvod MK Faktura za Proizvod Konfiguracija Specifikacije Proizvoda MK Specifikacija Proizvoda Specijalizovani MK Specifikacije Proizvoda MK Specifikacija Proizvoda Specijalizovani MK Specifikacije Proizvoda Dorada MK Dorada MK Konfiguracija 1 Specifikacije Proizvoda za nuđenje Specijalizovani MK Specifikacije proizvoda za nuđenje MK Specifikacija Proizvoda za nuđenje Dorada MK Konfiguracija 2 Specifikacije Proizvoda za nuđenje MK Specifikacija Proizvoda za nuđenje Specijalizovani MK Specifikacije proizvoda za nuđenje Dorada MK MK Uplata za Fakturu MK Faktura za Proizvod Specijalizovani MK Fakture za Proizvod Dorada MK Konfiguracija Fakture za Proizvod MK Specifikacija Proizvoda za nuđenje Slika 4.4. Šema za kreiranje modela karakteristika za oblast Upravljanje odnosom sa korisnikom. 84 Kreiranje MK Faktura za proizvod Na Nivou 4 – Obračun, postavlja se početni MK Specifikacija proizvoda za nuđenje. Automatskom specijalizacijom MK Specifikacija proizvoda za nuđenje koja se radi primenom konfiguracije 2 Specifikacija proizvoda za nuđenje dobija se početni MK Faktura za proizvod. Njegovom ručnom doradom dobija se MK Faktura za proizvod. Kreiranje konfiguracije MK Faktura za proizvod Na Nivou 4 – Obračun, iz MK Faktura za proizvod kreira se konfiguracija Faktura za proizvod. Kreiranje MK Uplata za fakturu Na Nivou 5 – Obezbeđenje prihoda, postavlja se početni MK Faktura za proizvod. Automatskom specijalizacijom MK Faktura za proizvod koja se radi primenom konfiguracije Faktura za proizvod dobija se početni MK Uplata za fakturu. Njegovom ručnom doradom dobija se MK Uplata za fakturu. 4.1.1.3. DEFINISANJE SISTEMA ZA HVFK KREIRANJE MK ZA FUNKCIONALNI DOMEN UPRAVLJANJE OPERATIVOM SERVISA Na Slici 4.5. se prikazuju osnovni poddomeni funkcionalne oblasti Upravljanje operativom servisa. Na Slici su jasno date zavisnosti između poddomena koje su sa leva na desno:  Specifikacija servisa je početni poddomen i od njega su zavisni poddomeni Konfiguracija i aktivacija servisa (Dizajn servisa) i Problemi na servisu. Razvoj proizvoda Ispunjenje (Realizacija) Obezbeđenje održavanja Obezbeđenje kvaliteta Obračun Obezbeđenje prihoda Specifikacija Servisa Konfiguracija i aktivacija Servisa (Dizajn Servisa) Problemi na Servisu Obračun za ServisPerformanse Servisa Uplata za Servis Slika 4.5. Funkcionalna oblast Upravljanje operativom servisa - poddomeni.  Konfiguracija i aktivacija servisa (Dizajn servisa) utiče na definisanje poddomena Performanse servisa i Obračun za servis.  Obračun za servis utiče na poddomen Uplata za servis. 85 Slika 4.5. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za HVFK kreiranje modela karakteristika za poddomen Upravljanje operativom servisa. Istovremeno na slici se vide i nazivi vertikalnih procesa kojima poddomeni pripadaju. Šema se dobija kada se mehanizam za kreiranje Modela karakteristika iz konfiguracija primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar funkcionalnog domena. Na Slici 4.6. prikazana je Šema za kreiranje modela karakteristika za oblast Upravljanje operativom servisa, primenom tehnike za višenivovsko fazno konfigurisanje. Šema ima šest nivoa konfigurisanja (od 0 do 5). Nivoe čine vertikalni procesi: 0 – Razvoj proizvoda, 1 - Ispunjenje (Realizacija), 2 – Obezbeđenje održavanja, 3 – Obezbeđenje kvaliteta, 4 – Obračun, 5 – Obezbeđenje prihoda. Višenivovsko fazno konfigurisanje po ovoj šemi odvija se sledećim redosledom: Ručno kreiranje MK Specifikacija servisa Na Nivou 0 - Razvoj proizvoda, kreira se ručno MK Specifikacija servisa. Zatim se ručno kreira Konfiguracija Specifikacije servisa. Kreiranje MK Konfiguracija i aktivacija servisa Na Nivou 1 - Ispunjenje (Realizacija), postavlja se početni MK Specifikacija servisa. Automatskom specijalizacijom MK Specifikacija servisa koja se radi primenom konfiguracije Specifikacije servisa dobija se početni MK Konfiguracija i aktivacija servisa. Njegovom ručnom doradom dobija se MK Konfiguracija i aktivacija servisa. Kreiranje MK Problemi na servisu Na Nivou 2 – Obezbeđenje održavanja, postavlja se početni MK Specifikacija servisa. Automatskom specijalizacijom MK Specifikacija servisa koja se radi primenom konfiguracije Specifikacije servisa dobija se početni MK Problemi na servisu. Njegovom ručnom doradom dobija se MK Problemi na servisu. Kreiranje dve konfiguracije MK Proizvod za nuđenje Na Nivou 1 - Ispunjenje (Realizacija), iz MK Konfiguracija i aktivacija servisa kreiraju se dve različite konfiguracije: Konfiguracija 1 Konfiguracija i aktivacija servisa i Konfiguracija 2 Konfiguracija i aktivacija servisa. 86 MK Specifikacija Servisa Faza 0 Faza 1 Faza 2 Nivo 0 Razvoj proizvoda Nivo 1 Ispunjenje (Realizacija) Nivo 2 Obezbeđenje održavanja Nivo 3 Obezbeđenje kvaliteta Nivo 4 Obračun Nivo 5 Obezbeđenje prihoda MK Problemi na Servisu MK Performanse servisa MK Obračun za Servis Konfiguracija Specifikacije Servisa MK Specifikacija Servia Specijalizovani MK Specifikacije Servisa MK Specifikacija Servisa Specijalizovani MK Specifikacije Servisa Dorada MK Dorada MK Konfiguracija 1 Koniguracije i Aktivacije Servisa Specijalizovani MK Konfiguracije i Aktivacije Servisa MK Konfiguracija i Aktivacija Servisa Dorada MK Konfiguracija 2 Koniguracije i Aktivacije Servisa MK Konfiguracija i Aktivacija Servisa Specijalizovani MK Konfiguracije i Aktivacije Servisa Dorada MK MK Uplata za Servis MK Obračun za Servis Specijalizovani MK Obračuna za Servis Dorada MK Konfiguracija Obračuna za Servis MK Konfiguracija i Aktivacija Servisa Slika 4.6. Šema za kreiranje modela karakteristika za oblast Upravljanje operativom servisa. 87 Kreiranje MK Performanse servisa Na Nivou 3 – Obezbeđenje kvaliteta, postavlja se početni MK Konfiguracija i aktivacija servisa Automatskom specijalizacijom MK Konfiguracija i aktivacija servisa koja se radi primenom konfiguracije 1 Konfiguracija i aktivacija servisa dobija se početni MK Performanse servisa. Njegovom ručnom doradom dobija se MK Performanse servisa. Kreiranje MK Obračun za servis Na Nivou 4 – Obračun, postavlja se početni MK Konfiguracija i aktivacija servisa. Automatskom specijalizacijom MK Konfiguracija i aktivacija servisa koja se radi primenom konfiguracije 2 Konfiguracija i aktivacija servisa dobija se početni MK Faktura za proizvod. Njegovom ručnom doradom dobija se MK Faktura za proizvod. Kreiranje konfiguracije MK Obračun za servis Na Nivou 4 – Obračun, iz MK Obračun za servis kreira se konfiguracija Obračun za servis. Kreiranje MK Uplata za fakturu Na Nivou 5 – Obezbeđenje prihoda, postavlja se početni MK Obračun za servis. Automatskom specijalizacijom MK Obračun za servis koja se radi primenom konfiguracije Obračun za servis dobija se početni MK Uplata za servis. Njegovom ručnom doradom dobija se MK Uplata za servis. 4.1.1.4. DEFINISANJE SISTEMA ZA HVFK KREIRANJE MK ZA FUNKCIONALNI DOMEN UPRAVLJANJE OPERATIVOM RESURSA Na Slici 4.7. se prikazuju osnovni poddomeni funkcionalne oblasti Upravljanje operativom resursa. Na Slici su jasno date zavisnosti između poddomena koje su sa leva na desno:  Specifikacija resursa je početni poddomen i od njega su zavisni poddomeni Provisioning resursa i Problemi na resursu.  Provisioning resursa utiče na definisanje poddomena Performanse resursa i Obračun za resurs.  Obračun za resurs utiče na poddomen Uplata za resurs (prepaid). 88 Slika 4.7. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za HVFK kreiranje modela karakteristika za poddomen Upravljanje operativom resursa. Istovremeno na slici se vide i nazivi vertikalnih procesa kojima poddomeni pripadaju. Šema se dobija kada se mehanizam za kreiranje Modela karakteristika iz konfiguracija primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar funkcionalnog domena. Razvoj proizvoda Ispunjenje (Realizacija) Obezbeđenje održavanja Obezbeđenje kvaliteta Obračun Obezbeđenje prihoda Specifikacija Resursa Provisioning Resursa Problemi na Resursu Obračun za Resurs Performanse Resursa Uplata za Resurs (Prepaid) Slika 4.7. Funkcionalna oblast Upravljanje operativom resursa - poddomeni. Na Slici 4.8. prikazana je Šema za kreiranje modela karakteristika za oblast Upravljanje operativom resursa, primenom tehnike za višenivovsko fazno konfigurisanje. Šema ima šest nivoa konfigurisanja (od 0 do 5). Nivoe čine vertikalni procesi: 0 – Razvoj proizvoda, 1 - Ispunjenje (Realizacija), 2 – Obezbeđenje održavanja, 3 – Obezbeđenje kvaliteta, 4 – Obračun, 5 – Obezbeđenje prihoda. Višenivovsko fazno konfigurisanje po ovoj šemi odvija se sledećim redosledom: Ručno kreiranje MK Specifikacija resursa Na Nivou 0 - Razvoj proizvoda, kreira se ručno MK Specifikacija resursa. Zatim se ručno kreira Konfiguracija Specifikacije resursa. Kreiranje MK Konfiguracija i aktivacija servisa Na Nivou 1 - Ispunjenje (Realizacija), postavlja se početni MK Specifikacija resursa. Automatskom specijalizacijom MK Specifikacija resursa koja se radi primenom konfiguracije Specifikacije resursa dobija se početni MK Provisioning resursa. Njegovom ručnom doradom dobija se MK Provisioning resursa. Kreiranje MK Problemi na resursu Na Nivou 2 – Obezbeđenje održavanja, postavlja se početni MK Specifikacija resursa. Automatskom specijalizacijom MK Specifikacija resursa koja se radi primenom 89 MK Specifikacija Resursa Faza 0 Faza 1 Faza 2 Nivo 0 Razvoj proizvoda Nivo 1 Ispunjenje (Realizacija) Nivo 2 Obezbeđenje održavanja Nivo 3 Obezbeđenje kvaliteta Nivo 4 Obračun Nivo 5 Obezbeđenje prihoda MK Problemi na Resursu MK Performanse Resursa MK Obračun za Resurs (Prepaid) Konfiguracija Specifikacije Resursa MK Specifikacija Resursa Specijalizovani MK Specifikacije Resursa MK Specifikacija Resursa Specijalizovani MK Specifikacije Resursa Dorada MK Dorada MK Konfiguracija 1 Provisioninga Resursa Specijalizovani MK Provisioninga Resursa MK Provisioning Resursa Dorada MK Konfiguracija 2 Provisioninga Resursa MK Provisioning Resursa Specijalizovani MK Provisioninga Resursa Dorada MK MK Uplata za Resurs (Prepaid) MK Obračun za Resurs Specijalizovani MK Obračuna za Resurs Dorada MK Konfiguracija Obračuna za Resurs MK Provisioning Resursa Slika 4.8. Šema za kreiranje modela karakteristika za oblast Upravljanje operativom resursa. 90 konfiguracije Specifikacije resursa dobija se početni MK Problemi na resursu. Njegovom ručnom doradom dobija se MK Problemi na resursu. Kreiranje dve konfiguracije MK Provisioning resursa Na Nivou 1 - Ispunjenje (Realizacija), iz MK Provisioning resursa kreiraju se dve različite konfiguracije: Konfiguracija 1 Provisioning resursa i Konfiguracija 2 Provisioning resursa. Kreiranje MK Performanse resursa Na Nivou 3 – Obezbeđenje kvaliteta, postavlja se početni MK Provisioning resursa Automatskom specijalizacijom MK Provisioning resursa koja se radi primenom konfiguracije 1 Provisioning resursa dobija se početni MK Performanse resursa. Njegovom ručnom doradom dobija se MK Performanse resursa. Kreiranje MK Obračun za resurs (prepaid) Na Nivou 4 – Obračun, postavlja se početni MK Provisioning resursa. Automatskom specijalizacijom MK Provisioning resursa koja se radi primenom konfiguracije 2 Provisioning resursa dobija se početni MK Obračun za resurs (prepaid). Njegovom ručnom doradom dobija se MK Obračun za resurs (prepaid). Kreiranje konfiguracije MK Obračun za resurs (prepaid) Na Nivou 4 – Obračun, iz MK Obračun za resurs (prepaid) kreira se konfiguracija Obračun za resurs (prepaid). Kreiranje MK Uplata za resurs (prepaid) Na Nivou 5 – Obezbeđenje prihoda, postavlja se početni MK Obračun za resurs (prepaid). Automatskom specijalizacijom MK Obračun za resurs (prepaid) koja se radi primenom konfiguracije Obračun za resurs (prepaid) dobija se početni MK Uplata za resurs (prepaid). Njegovom ručnom doradom dobija se MK Uplata za resurs (prepaid). 4.1.1.5. DEFINISANJE SISTEMA ZA HVFK KREIRANJE MK ZA FUNKCIONALNI DOMEN UPRAVLJANJE ODNOSOM SA DOBAVLJAČEM / PARTNEROM 91 Na Slici 4.9. se prikazuju osnovni poddomeni funkcionalne oblasti Upravljanje odnosom sa dobavljačem/partnerom. Na Slici su jasno date zavisnosti između poddomena koje su sa leva na desno:  Specifikacija resursa dobavljača/partnera (Ugovor sa D/P) je početni poddomen i od njega su zavisni poddomeni Zahtev za realizaciju za dobavljača/partnera, Problemi na resursu za dobavljača/partnera, Obezbeđenje kvaliteta resursa od dobavljača/partnera i Prebijanje obračuna sa dobavljačem/partnerom.  Prebijanje obračuna sa dobavljačem/partnerom utiče na poddomen Uplate/Isplate sa dobavljačem/partnerom. Slika 4.9. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za HVFK kreiranje modela karakteristika za poddomen Upravljanje odnosom sa dobavljačem/partnerom. Istovremeno na slici se vide i nazivi vertikalnih procesa kojima poddomeni pripadaju. Šema se dobija kada se mehanizam za kreiranje Modela karakteristika iz konfiguracija primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar funkcionalnog domena. Razvoj proizvoda Ispunjenje (Realizacija) Obezbeđenje održavanja Obezbeđenje kvaliteta Obračun Obezbeđenje prihoda Zahtev za realizaciju D/P Problemi na resursu za D/P Prebijanje Obračuna sa D/P Obezbeđenje kvaliteta resursa od D/P Uplate/Isplate D/P Specifikacija Resursa D/P (Ugovor sa D/P) Slika 4.9. Funkcionalna oblast Upravljanje odnosom sa dobavljačem/partnerom - poddomeni. Na Slici 4.10. prikazana je Šema za kreiranje modela karakteristika za oblast Upravljanje odnosom sa dobavljačem/partnerom, primenom tehnike za višenivovsko fazno konfigurisanje. Šema ima šest nivoa konfigurisanja (od 0 do 5). Nivoe čine vertikalni procesi: 0 – Razvoj proizvoda, 1 - Ispunjenje (Realizacija), 2 – Obezbeđenje održavanja, 3 – Obezbeđenje kvaliteta, 4 – Obračun, 5 – Obezbeđenje prihoda. Višenivovsko fazno konfigurisanja po ovoj šemi odvija se sledećim redosledom: Ručno kreiranje MK Specifikacija resursa D/P Na Nivou 0 - Razvoj proizvoda, kreira se ručno MK Specifikacija resursa D/P. Zatim se ručno kreira Konfiguracija 1 Specifikacije resursa D/P. 92 MK Specifikacija Resursa D/P Faza 0 Faza 1 Faza 2 Nivo 0 Razvoj proizvoda Nivo 1 Ispunjenje (Realizacija) Nivo 2 Obezbeđenje održavanja Nivo 3 Obezbeđenje kvaliteta Nivo 4 Obračun Nivo 5 Obezbeđenje prihoda MK Problemi na Resursu za D/P MK Prebijanje obračuna za D/P Konfiguracija 1 Specifikacije Resursa D/P MK Specifikacija Resursa D/P Specijalizovani MK Specifikacije Resursa D/P MK Specifikacija Resursa D/P Specijalizovani MK Specifikacije Resursa D/P Dorada MK Dorada MK Dorada MK Specijalizovani MK Specifikacije Resursa D/P Dorada MK MK Uplate/Isplate za D/P MK Prebijanje Obračuna za D/P Specijalizovani MK Prebijanje obračuna za D/P Dorada MK Konfiguracija Prebijanja obračuna za D/P MK Zahtev za realizaciju D/P Konfiguracija 3 Specifikacije Resursa D/P Konfiguracija 4 Specifikacije Resursa D/P Specijalizovani MK Specifikacije Resursa D/P MK Specifikacija Resursa D/P MK Obezbeđenje kvaliteta resursa od D/P Faza 3 MK Specifikacija Resursa D/P Konfiguracija 2 Specifikacije Resursa D/P Faza 4 Slika 4.10. Šema za kreiranje modela karakteristika za oblast Upravljanje odnosom sa Dobavljačem/Partnerom. 93 Kreiranje MK Zahtev za realizaciju D/P Na Nivou 1 - Ispunjenje (Realizacija), postavlja se početni MK Specifikacija resursa D/P. Automatskom specijalizacijom MK Specifikacija resursa D/P koja se radi primenom konfiguracije 1 Specifikacije resursa D/P dobija se početni MK Zahtev za realizaciju D/P. Njegovom ručnom doradom dobija se MK Zahtev za realizaciju D/P Kreiranje tri nove konfiguracije MK Specifikacija resursa D/P Na Nivou 1 - Ispunjenje (Realizacija), iz MK Specifikacija resursa D/P kreiraju se još tri različite konfiguracije: Konfiguracija 2 Specifikacija resursa D/P, Konfiguracija 3 Specifikacija resursa D/P, Konfiguracija 4 Specifikacija resursa D/P. Kreiranje MK Problemi na resursu za D/P Na Nivou 2 – Obezbeđenje održavanja, postavlja se početni MK Specifikacija resursa D/P Automatskom specijalizacijom MK Specifikacija resursa D/P koja se radi primenom konfiguracije 2 Specifikacija resursa D/P dobija se početni MK Problemi na resursu za D/P. Njegovom ručnom doradom dobija se MK Problemi na resursu za D/P. Kreiranje MK Obezbeđenje kvaliteta resursu od D/P Na Nivou 3 – Obezbeđenje kvaliteta, postavlja se početni MK Specifikacija resursa D/P Automatskom specijalizacijom MK Specifikacija resursa D/P koja se radi primenom konfiguracije 3 Specifikacija resursa D/P dobija se početni MK Obezbeđenje kvaliteta resursu od D/P. Njegovom ručnom doradom dobija se MK Obezbeđenje kvaliteta resursu od D/P. Kreiranje MK Prebijanje obračuna sa D/P Na Nivou 4 – Obračun, postavlja se početni MK Specifikacija resursa D/P Automatskom specijalizacijom MK Specifikacija resursa D/P koja se radi primenom konfiguracije 4 Specifikacija resursa D/P dobija se početni MK Prebijanje obračuna sa D/P. Njegovom ručnom doradom dobija se MK Prebijanje obračuna sa D/P. Kreiranje konfiguracije MK Prebijanje obračuna sa D/P Na Nivou 4 – Obračun, iz MK Prebijanje obračuna sa D/P kreira se konfiguracija Prebijanje obračuna sa D/P. 94 Kreiranje MK Uplate/Isplate za D/P Na Nivou 5 – Obezbeđenje prihoda, postavlja se početni MK Prebijanje obračuna sa D/P. Automatskom specijalizacijom MK Prebijanje obračuna sa D/P koja se radi primenom konfiguracije Prebijanje obračuna sa D/P dobija se početni MK plate/Isplate za D/P. Njegovom ručnom doradom dobija se MK Uplate/Isplate za D/P. 4.1.2. DEFINISANJE SISTEMA ZA VERTIKALNO VIŠENIVOVSKO FAZNO KONFIGURISANJE (VVFK) TELEKOMUNIKACIONOG DOMENA Sistem za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) se realizuje kroz šest šema. Šema ima onoliko koliko i vertikalnih procesa, od koji svaka ima od 0 do 3 nivoa konfigurisanja (Slika 4.11.). Redosled njihovog definisanja i izvođenja je sa leva na desno (Slika u poglavlju 3). Glavni rezultat izvršenja vertikalne višenivovske fazne konfiguracije je realizacija razvoja vertikalnih procesa kroz višenivovsku faznu transformaciju Modela karakteristika gde rezultat (konfiguracija) sa prethodnog nivoa predstavlja ulazne parametre za izradu modela karakteristika na donjem nivou:  Definisanje osnovnog VVFK mehanizma, koji je već objašnjen detaljno u poglavlju tri, čime se obezbeđuje tehnika za definisanje pojedinačnih šema za višenivovsko fazno konfigurisanje.  Definisanje sistema za VVFK za klasu procesa Razvoj Proizvoda omogućava razvoj ove vertikalne klase procesa. Sistem se realizuje preko Šeme VVFK za klasu procesa Razvoj proizvoda.  Definisanje sistema za VVFK za klasu procesa Ispunjenje (Realizacija) omogućava razvoj ove vertikalne klase procesa. Sistem se realizuje preko Šeme VVFK za klasu procesa Ispunjenje (Realizacija).  Definisanje sistema za VVFK za klasu procesa Obezbeđenje održavanja omogućava razvoj ove vertikalne klase procesa. Sistem se realizuje preko Šeme VVFK za klasu procesa Obezbeđenje održavanja.  Definisanje sistema za VVFK za klasu procesa Obezbeđenje kvaliteta omogućava razvoj ove vertikalne klase procesa. Sistem se realizuje preko Šeme VVFK za klasu procesa Obezbeđenje kvaliteta. 95 In že n je rs tv o d o m en sk ih z ah te va O P ŠT I D O M EN SK I I N ŽE N JE R IN G D iz aj n d o m en a R ea liz ac ija d o m en a Te st ir an je d o m en a Definisanje sistema za VVFK za klasu procesa Razvoj Proizvoda Definisanje sistema za VVFK za klasu procesa Ispunjenje (Realizacija) Definisanje sistema za VVFK za klasu procesa Obezbeđenje održavanja Definisanje sistema za VVFK za klasu procesa Obezbeđenje kvaliteta Definisanje osnovnog VVFK mehanizma Osnovni VVFK mehanizam Šema VVFK za klasu procesa Razvoj proizvoda Šema VVFK za klasu procesa Ispunjenje (Realizacija) Šema VVFK za klasu procesa Obezbeđenje održavanja Šema VVFK za klasu procesa Obezbeđenje kvaliteta Definisanje sistema za VVFK za klasu procesa Obezbeđenje prihoda Definisanje sistema za VVFK za klasu procesa Obračun Šema VVFK za klasu procesa Obračun Šema VVFK za klasu procesa Obezbeđenje prihoda NGOSS – SID Definisanje šeme za Višenivovsko Fazno Konfigurisanje Telekomunikacionog Domena (VFKTD) Definisanje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) VFKTD šema telekomunikacionog domena Definisanje sistema za Generisanje IS NGOSS – eTOM NGOSS – SID Šeme i mehanizmi HVFK sistema Šeme i mehanizmi VVFK sistema Šeme I mehanizmi za generisanje IS Testiranje sistema Testovi HVFK, VVFK, IS Definisanje sistema za VertikalnoVišenivovsko Fazno Konfigurisanje (VVFK) Slika 4.11. Opšti domenski inženjering – Definisanje VVFK sistema (treći nivo dekompozicije). 96  Definisanje sistema za VVFK za klasu procesa Obračun omogućava razvoj ove vertikalne klase procesa. Sistem se realizuje preko Šeme VVFK za klasu procesa Obračun.  Definisanje sistema za VVFK za klasu procesa Obezbeđenje prihoda omogućava razvoj ove vertikalne klase procesa. Sistem se realizuje preko Šeme VVFK za klasu procesa Obezbeđenje prihoda. 4.1.2.1. VERTIKALNO VIŠENIVOVSKO KONFIGURISANJE KLASE PROCESA „RAZVOJ PROIZVODA“ Na Slici 4.12. prikazuju se osnovni poddomeni Vertikalne grupe procesa Razvoj proizvoda. Na Slici su jasno date zavisnosti između poddomena koje su odozgo na dole: Slika 4.12. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za VVFK modela karakteristika za vertikalnu klasu procesa Razvoj proizvoda. Istovremeno na slici se vide i nazivi horizontalnih procesa kojima poddomeni pripadaju. VVFK šema se dobija kada se osnovni mehanizam za višenivovsko fazno konfigurisanje primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar klase vertikalnog procesa. Na Slici 4.13. prikazana je Šema za vertikalno višenivovsko fazno konfigurisanje za klasu procesa Razvoj proizvoda. Šema ima četiri nivoa konfigurisanja (od 0 do 3). Nivoe čine funkcionalne oblasti: 0 – Upravljanje odnosom sa korisnikom, 1 – Upravljanje operativom servisa, 2 – Upravljanje operativom resursa, 3 – Upravljanje odnosom sa dobavljačem partnerom. Višenivovsko fazno konfigurisanje po ovoj šemi obezbeđuje automatizovano krojenje modela karakteristika koji su izgrađeni kroz proces Specifikacija Proizvoda Specifikacija Servisa Specifikacija Resursa Specifikacija Resursa D/P (Ugovor sa D/P) HP Nivo 0 Upravljanje odnosom sa Korisnikom HP Nivo 1 Upravljanje operativom Servisa HP Nivo 2 Upravljanje operativom Resursa HP Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Slika 4.12. Razvoj proizvoda. 97 horizontalnog višenivovskog faznog konfigurisanja. VVFK proces se odvija kroz sledeći redosled aktivnosti: Ručno konfigurisanje MK Specifikacija proizvoda Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je MK Specifikacija proizvoda iz koga se kreira ručno konfiguracija Specifikacija proizvoda. Automatsko krojenje (specijalizacija) MK Specifikacija servisa Na Nivou 1 – Upravljanje operativom servisa, postavlja se početni MK Specifikacija servisa. Automatskom specijalizacijom MK Specifikacija servisa koja se radi primenom konfiguracije Specifikacije proizvoda dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Specifikacija servisa. Suštinsko značenje ovoga je automatska transformacija koncepta Proizvod u koncept Servis gde Proizvod predstavlja specifikaciju a Servis njegovu realizaciju. Ručno konfigurisanje MK Specifikacija servisa Na Nivou 1 - Upravljanje operativom servisa, iz skrojenog MK Specifikacija servisa kreira se ručno konfiguracija Specifikacija servisa. Automatsko krojenje (specijalizacija) MK Specifikacija resursa Na Nivou 2 – Upravljanje operativom resursa, postavlja se početni MK Specifikacija resursa. Automatskom specijalizacijom MK Specifikacija resursa koja se radi primenom konfiguracije Specifikacije servisa dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Specifikacija resursa. Suštinsko značenje ovoga je automatska transformacija koncepta Servis u koncept Resurs gde Servis predstavlja specifikaciju a Resurs njegovu realizaciju. Ručno konfigurisanje MK Specifikacija resursa Na Nivou 2 - Upravljanje operativom resurs, iz skrojenog MK Specifikacija resursa kreira se ručno konfiguracija Specifikacija resursa. Automatsko krojenje (specijalizacija) MK Specifikacija resursa za D/P Na Nivou 3 – Upravljanje odnosom sa D/P, postavlja se početni MK Specifikacija resursa D/P. Automatskom specijalizacijom MK Specifikacija resursa D/P koja se radi primenom konfiguracije Specifikacije resursa dobija se specijalizovani (skrojen prema 98 Višenivovsko konfigurisanje za Klasu procesa «Razvoj proizvoda» Nivo 0 Upravljanje odnosom sa Korisnikom Nivo 1 Upravljanje operativom Servisa Nivo 2 Upravljanje operativom Resursa Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Nivo 0 – MK Specifikacija Proizvoda Nivo 0 Konfiguracija Specifikacije Proizvoda Nivo 1 - MK Specifikacija Servisa Nivo 1 – MK Specijalizacija Specifikacije Servisa Proces Specijalizacije Specifikacije Servisa Nivo 1 Konfiguracija Speciikacije Servisa Nivo 2 - MK Specifikacija Resursa Nivo 2 – MK Specijalizacija SpecifikacijE Resursa Proces Specijalizacije Specifikacije Resursa Proces Konfigurisanja Specikacije Proizvoda Proces Konfigurisanja Speciikacije Servisa Nivo 2 Konfiguracija Specifikacije Resursa Proces Konfigurisanja Specifikacije Resursa Nivo 3 - MK Specifikacija Resursa D/P Nivo 3 – MK Specijalizacija Specifikacija Resursa D/P Nivo 3 Konfiguracija Specifikacije Resursa D/P Proces Konfigurisanja Specifikacije Resursa D/P Proces Specijalizacije Specifikacije Resursa D/P Faza 0 Faza 1 Faza 2 Faza 3 Slika 4.13. Vertikalno višenivovsko konfigurisanje klase procesa „Razvoj proizvoda“. 99 konfiguraciji sa višeg nivoa) MK Specifikacija resursa D/P. Suštinsko značenje ovoga je automatska transformacija koncepta Resurs u koncept Resurs D/P gde Resurs predstavlja specifikaciju a Resurs D/P njegovu realizaciju. Ručno konfigurisanje MK Specifikacija resursa D/P Na Nivou 3 - Upravljanje odnosom sa D/P, iz skrojenog MK Specifikacija resursa D/P kreira se ručno konfiguracija Specifikacija resursa D/P. 4.1.2.3. VERTIKALNO VIŠENIVOVSKO KONFIGURISANJE KLASE PROCESA „ISPUNJENJE (REALIZACIJA)“ Na Slici 4.14. prikazuju se osnovni poddomeni Vertikalne grupe procesa Ispunjenje (Realizacija). Na Slici su jasno date zavisnosti između poddomena (zavisnosti su odozgo na dole:) Slika 4.14. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za VVFK modela karakteristika za vertikalnu klasu procesa Ispunjenje (Realizacija). Istovremeno na slici se vide i nazivi horizontalnih procesa kojima poddomeni pripadaju. VVFK šema se dobija kada se osnovni mehanizam za višenivovsko fazno konfigurisanje primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar klase vertikalnog procesa. Na Slici 4.15. prikazana je Šema za vertikalno višenivovsko fazno konfigurisanje za klasu procesa Ispunjenje (Realizacija). Šema ima četiri nivoa konfigurisanja (od 0 do 3). Nivoe čine funkcionalne oblasti: 0 – Upravljanje odnosom sa korisnikom, 1 – Upravljanje operativom servisa, 2 – Upravljanje operativom resursa, 3 – Upravljanje odnosom sa dobavljačem partnerom. Višenivovsko fazno konfigurisanje po ovoj šemi obezbeđuje automatizovano krojenje HP Nivo 0 Upravljanje odnosom sa Korisnikom HP Nivo 1 Upravljanje operativom Servisa HP Nivo 2 Upravljanje operativom Resursa HP Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Slika 4.14. Ispunjenje (Realizacija) Specifikacija Proizvoda za nuđenje Konfiguracija i aktivacija Servisa (Dizajn Servisa) Provisioning Resursa Zahtev za realizaciju D/P 100 Višenivovsko konfigurisanje za Klasu procesa «Ispunjenje (Realizacija)» Nivo 0 Upravljanje odnosom sa Korisnikom Nivo 1 Upravljanje operativom Servisa Nivo 2 Upravljanje operativom Resursa Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Nivo 0 – MK Specifikacija Proizvoda za nuđenje Nivo 0 Konfiguracija Specifikacije Proizvoda za nuđenje Nivo 1 - MK Dizajn Servisa Nivo 1 – MK Specijalizacija Dizajna Servisa Proces Specijalizacije Dizajna Servisa Nivo 1 Konfiguracija Dizajna Servisa Nivo 2 - MK Provisioning Resursa Nivo 2 – MK Specijalizacija Provisioninga Resursa Proces Specijalizacije Provisioninga Resursa Proces Konfigurisanja Specifikacije Proizvoda za nuđenje Proces Konfigurisanja Dizajna Servisa Nivo 2 Konfiguracija Provisioninga Resursa Proces Konfigurisanja Provisioninga Resursa Nivo 3 - MK Zahtev za realizaciju D/P Nivo 3 – MK Specijalizacija Zahteva za realizaciju D/P Nivo 3 Konfiguracija Zahteva za realizaciju D/P Proces Konfigurisanja Zahteva za realizaciju D/P Proces Specijalizacije Zahteva za realizaciju D/P Faza 0 Faza 1 Faza 2 Faza 3 Slika 4.15. Vertikalno višenivovsko konfigurisanje za klasu procesa „Ispunjenje (Realizacija)“. 101 modela karakteristika za proces Ispunjenje (Realizacija). MK su izgrađeni kroz proces horizontalnog višenivovskog faznog konfigurisanja. VVFK proces se odvija kroz sledeći redosled aktivnosti: Ručno konfigurisanje MK Specifikacija proizvoda za nuđenje Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je MK Specifikacija proizvoda za nuđenje iz koga se kreira ručno konfiguracija Specifikacija proizvoda za nuđenje. Automatsko krojenje (specijalizacija) MK Dizajn servisa Na Nivou 1 – Upravljanje operativom servisa, postavlja se početni MK Dizajn servisa. Automatskom specijalizacijom MK Dizajn servisa koja se radi primenom konfiguracije Specifikacije proizvoda za nuđenje dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Dizajn servisa. Suštinsko značenje ovoga je automatska transformacija poddomena Specifikacija proizvoda za nuđenje u poddomen Dizajn servisa gde Specifikacija proizvoda za nuđenje predstavlja specifikaciju a Dizajn servisa njegovu realizaciju. Ručno konfigurisanje MK Dizajn servisa Na Nivou 1 - Upravljanje operativom servisa, iz skrojenog MK Dizajn servisa kreira se ručno konfiguracija Dizajn servisa. Automatsko krojenje (specijalizacija) MK Provisioning resursa Na Nivou 2 – Upravljanje operativom resursa, postavlja se početni MK Provisioning resursa. Automatskom specijalizacijom MK Provisioning resursa koja se radi primenom konfiguracije Dizajn servisa dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Provisioning resursa. Suštinsko značenje ovoga je automatska transformacija poddomena Dizajn servisa u poddomen Provisioning resursa gde Dizajn servisa predstavlja specifikaciju a Provisioning resursa njegovu realizaciju. Ručno konfigurisanje MK Provisioning resursa Na Nivou 2 - Upravljanje operativom resurs, iz skrojenog MK Provisioning resursa kreira se ručno konfiguracija Provisioning resursa. Automatsko krojenje (specijalizacija) MK Zahtev za realizaciju D/P 102 Na Nivou 3 – Upravljanje odnosom sa D/P, postavlja se početni MK Zahtev za realizaciju D/P. Automatskom specijalizacijom MK Zahtev za realizaciju D/P koja se radi primenom konfiguracije Provisioning resursa dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Zahtev za realizaciju D/P. Suštinsko značenje ovoga je automatska transformacija poddomena Provisioning resursa u poddomen Zahtev za realizaciju D/P gde Provisioning resursa predstavlja specifikaciju a Zahtev za realizaciju D/P njegovu realizaciju. Ručno konfigurisanje MK Zahtev za realizaciju D/P Na Nivou 3 - Upravljanje odnosom sa D/P, iz skrojenog MK Zahtev za realizaciju D/P kreira se ručno konfiguracija Zahtev za realizaciju D/P. 4.1.2.4. VERTIKALNO VIŠENIVOVSKO KONFIGURISANJE KLASE PROCESA „OBEZBEĐENJE ODRŽAVANJA“ Na Slici 4.16. prikazuju se osnovni poddomeni Vertikalne grupe procesa Obezbeđenje održavanja. Na Slici su jasno date zavisnosti između poddomena (zavisnosti su odozgo na dole:) Slika 4.16. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za VVFK modela karakteristika za vertikalnu klasu procesa Obezbeđenje održavanja. Istovremeno na slici se vide i nazivi horizontalnih procesa kojima poddomeni pripadaju. VVFK šema se dobija kada se osnovni mehanizam za višenivovsko fazno konfigurisanje primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar klase vertikalnog procesa. Na Slici 4.17. prikazana je Šema za vertikalno višenivovsko fazno konfigurisanje za klasu procesa Obezbeđenje održavanja. Šema ima četiri nivoa konfigurisanja (od 0 do 3). Nivoe čine funkcionalne oblasti: 0 – Upravljanje odnosom sa korisnikom, 1 – Upravljanje operativom servisa, 2 – Upravljanje operativom resursa, 3 – Upravljanje odnosom sa dobavljačem partnerom. Višenivovsko fazno konfigurisanje po ovoj šemi obezbeđuje automatizovano krojenje modela karakteristika za proces Obezbeđenje održavanja. MK su izgrađeni kroz proces horizontalnog višenivovskog faznog konfigurisanja. VVFK proces se odvija kroz sledeći redosled aktivnosti: Ručno konfigurisanje MK Problemi proizvoda 103 Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je MK Problemi proizvoda iz koga se kreira ručno konfiguracija Problemi proizvoda. Automatsko krojenje (specijalizacija) MK Problemi na servisu Na Nivou 1 – Upravljanje operativom servisa, postavlja se početni MK Problemi na servisu. Automatskom specijalizacijom MK Problemi na servisu koja se radi primenom konfiguracije Problemi proizvoda za nuđenje dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Problemi na servisu. Suštinsko značenje ovoga je automatska transformacija poddomena Problemi proizvoda u poddomen Problemi na servisu gde Problemi proizvoda predstavlja specifikaciju a Problemi na servisu njegovu realizaciju. Ručno konfigurisanje MK Problemi na servisu Na Nivou 1 - Upravljanje operativom servisa, iz skrojenog MK Problemi na servisu kreira se ručno konfiguracija Problemi na servisu. Automatsko krojenje (specijalizacija) MK Problemi na resursu Na Nivou 2 – Upravljanje operativom resursa, postavlja se početni MK Problemi na resursu. Automatskom specijalizacijom MK Problemi na resursu koja se radi primenom konfiguracije Problemi na servisu dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Problemi na resursu. Suštinsko značenje ovoga je automatska transformacija poddomena Problemi na servisu u poddomen Problemi na resursu gde Problemi na servisu predstavlja specifikaciju a Problemi na resursu njegovu realizaciju. Ručno konfigurisanje MK Problemi na resursu Na Nivou 2 - Upravljanje operativom resurs, iz skrojenog MK Problemi na resursu kreira se ručno konfiguracija Problemi na resursu. HP Nivo 0 Upravljanje odnosom sa Korisnikom HP Nivo 1 Upravljanje operativom Servisa HP Nivo 2 Upravljanje operativom Resursa HP Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Slika 4.16. Obezbeđenje održavanja. Problemi Proizvoda Problemi na Servisu Problemi na Resursu Problemi na resursu za D/P 104 Višenivovsko konfigurisanje za Klasu procesa «Obezbeđenje održavanja» Nivo 0 Upravljanje odnosom sa Korisnikom Nivo 1 Upravljanje operativom Servisa Nivo 2 Upravljanje operativom Resursa Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Nivo 0 – MK Problemi Proizvoda Nivo 0 Konfiguracija Problema Proizvoda Nivo 1 - MK Problemi na Servisu Nivo 1 – MK Specijalizacija Problemi na Servisu Proces Specijalizacije Problema na Servisu Nivo 1 Konfiguracija Problema na Servisu Nivo 2 - MK Problemi na Resursu Nivo 2 – MK Specijalizacija Problemi na Resursu Proces Specijalizacije Problema na Resursu Proces Konfigurisanja Problema Proizvoda Proces Konfigurisanja Problema na Servisu Nivo 2 Konfiguracija Problema na Resursu Proces Konfigurisanja Problema na Resursu Nivo 3 - MK Problimi Resursa za D/P Nivo 3 – MK Specijalizacija Problema Resursa za D/P Nivo 3 Konfiguracija Problema na Resursu Za D/P Proces Konfigurisanja Problema Resursa za D/P Proces Specijalizacije Problema Resursa za D/P Faza 0 Faza 1 Faza 2 Faza 3 Slika 4.17. Vertikalno višenivovsko konfigurisanje klase procesa „Obezbeđenje održavanja“. 105 Automatsko krojenje (specijalizacija) MK Problemi resursa za D/P Na Nivou 3 – Upravljanje odnosom sa D/P, postavlja se početni MK Problemi resursa za D/P. Automatskom specijalizacijom MK Problemi resursa za D/P koja se radi primenom konfiguracije Problemi na resursu dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Problemi resursa za D/P. Suštinsko značenje ovoga je automatska transformacija poddomena Problemi na resursu u poddomen Problemi resursa za D/P gde Problemi na resursu predstavlja specifikaciju a Problemi resursa za D/P njegovu realizaciju. Ručno konfigurisanje MK Problemi resursa za D/P Na Nivou 3 - Upravljanje odnosom sa D/P, iz skrojenog MK Problemi resursa za D/P kreira se ručno konfiguracija Problemi resursa za D/P. 4.1.2.5. VERTIKALNO VIŠENIVOVSKO KONFIGURISANJE KLASE PROCESA „OBEZBEĐENJE KVALITETA“ Na Slici 4.18. prikazuju se osnovni poddomeni Vertikalne grupe procesa Obezbeđenje kvaliteta. Na Slici su jasno date zavisnosti između poddomena (zavisnosti su odozgo na dole:) Slika 4.18. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za VVFK modela karakteristika za vertikalnu klasu procesa Obezbeđenje kvaliteta. Istovremeno na slici se vide i nazivi horizontalnih procesa kojima poddomeni pripadaju. VVFK šema se dobija kada se osnovni mehanizam za višenivovsko fazno konfigurisanje primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar klase vertikalnog procesa. Na Slici 4.19. prikazana je Šema za vertikalno višenivovsko fazno konfigurisanje za klasu procesa Obezbeđenje kvaliteta. Šema HP Nivo 0 Upravljanje odnosom sa Korisnikom HP Nivo 1 Upravljanje operativom Servisa HP Nivo 2 Upravljanje operativom Resursa HP Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Slika 4.18. Obezbeđenje kvaliteta. SLA za Proizvod Performanse Servisa Performanse Resursa Obezbeđenje kvaliteta resursa od D/P 106 Višenivovsko konfigurisanje za Klasu procesa «Obezbeđenje kvaliteta» Nivo 0 Upravljanje odnosom sa Korisnikom Nivo 1 Upravljanje operativom Servisa Nivo 2 Upravljanje operativom Resursa Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Nivo 0 – MK SLA za Proizvod Nivo 0 Konfiguracija SLA za Proizvod Nivo 1 - MK Performanse Servisa Nivo 1 – MK Specijalizacija Performansi Servis Proces Specijalizacije Performansi Servisa Nivo 1 Konfiguracija Performansi Servisa Nivo 2 - MK Perormanse Resursa Nivo 2 – MK Specijalizacija Performansi Resursa Proces Specijalizacije Performansi Resursa Proces Konfigurisanja SLA za Proizvod Proces Konfigurisanja Performansi Servisa Nivo 2 Konfiguracija Performansi Resursa Proces Konfigurisanja Perormansi Resursa Nivo 3 - MK Obezbeđenje kvaliteta Resursa od D/P Nivo 3 – MK Specijalizacija Obezbeđenja Kvaliteta Resursa od D/P Nivo 3 Konfiguracija Obezbeđenja Kvaliteta Resursa od D/P Proces Konfigurisanja Obezbeđenja Kvaliteta Resursa od D/P Proces Specijalizacije Obezbeđenja Kvaliteta Resursa D/P Faza 0 Faza 1 Faza 2 Faza 3 Slika 4.19. Vertikalno višenivovsko konfigurisanje klase procesa „Obezbeđenje kvaliteta“. 107 ima četiri nivoa konfigurisanja (od 0 do 3). Nivoe čine funkcionalne oblasti: 0 – Upravljanje odnosom sa korisnikom, 1 – Upravljanje operativom servisa, 2 – Upravljanje operativom resursa, 3 – Upravljanje odnosom sa dobavljačem partnerom. Višenivovsko fazno konfigurisanje po ovoj šemi obezbeđuje automatizovano krojenje modela karakteristika za proces Obezbeđenje kvaliteta. MK su izgrađeni kroz proces horizontalnog višenivovskog faznog konfigurisanja. VVFK proces se odvija kroz sledeći redosled aktivnosti: Ručno konfigurisanje MK SLA za proizvod Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je MK SLA za proizvod iz koga se kreira ručno konfiguracija SLA za proizvod. Automatsko krojenje (specijalizacija) MK Performanse servisa Na Nivou 1 – Upravljanje operativom servisa, postavlja se početni MK Performanse servisa. Automatskom specijalizacijom MK Performanse servisa koja se radi primenom konfiguracije SLA za proizvod dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Performanse servisa. Suštinsko značenje ovoga je automatska transformacija poddomena SLA za proizvod u poddomen Performanse servisa gde SLA za proizvod predstavlja specifikaciju a Performanse servisa njegovu realizaciju. Ručno konfigurisanje MK Performanse servisa Na Nivou 1 - Upravljanje operativom servisa, iz skrojenog MK Performanse servisa kreira se ručno konfiguracija Performanse servisa. Automatsko krojenje (specijalizacija) MK Performanse resursa Na Nivou 2 – Upravljanje operativom resursa, postavlja se početni MK Performanse resursa. Automatskom specijalizacijom MK Performanse resursa koja se radi primenom konfiguracije Performanse servisa dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Performanse resursa. Suštinsko značenje ovoga je automatska transformacija poddomena Performanse servisa u poddomen Performanse resursa gde Performanse servisa predstavlja specifikaciju a Performanse resursa njegovu realizaciju. Ručno konfigurisanje MK Performanse resursa 108 Na Nivou 2 - Upravljanje operativom resurs, iz skrojenog MK Performanse resursa kreira se ručno konfiguracija Performanse resursa. Automatsko krojenje (specijalizacija) MK Obezbeđenje kvaliteta resursa od D/P Na Nivou 3 – Upravljanje odnosom sa D/P, postavlja se početni MK Obezbeđenje kvaliteta resursa od D/P. Automatskom specijalizacijom MK Obezbeđenje kvaliteta resursa od D/P koja se radi primenom konfiguracije Performanse resursa dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Obezbeđenje kvaliteta resursa od D/P. Suštinsko značenje ovoga je automatska transformacija poddomena Performanse resursa u poddomen Obezbeđenje kvaliteta resursa od D/P gde Performanse resursa predstavlja specifikaciju a Obezbeđenje kvaliteta resursa od D/P njegovu realizaciju. Ručno konfigurisanje MK Obezbeđenje kvaliteta resursa od D/P Na Nivou 3 - Upravljanje odnosom sa D/P, iz skrojenog MK Obezbeđenje kvaliteta resursa od D/P kreira se ručno konfiguracija Obezbeđenje kvaliteta resursa od D/P. 4.1.2.6. VERTIKALNO VIŠENIVOVSKO KONFIGURISANJE KLASE PROCESA „OBRAČUN“ Na Slici 4.20. prikazuju se osnovni poddomeni Vertikalne grupe procesa Obračun. Na Slici su jasno date zavisnosti između poddomena (zavisnosti su odozgo na dole) Slika 4.20. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za VVFK modela karakteristika za vertikalnu klasu procesa Obračun. Istovremeno na slici se vide i nazivi horizontalnih procesa kojima poddomeni pripadaju. VVFK šema se dobija kada se osnovni mehanizam za višenivovsko fazno konfigurisanje primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar klase vertikalnog procesa. Na Slici 4.21. prikazana je Šema za vertikalno višenivovsko fazno konfigurisanje za klasu procesa Obračun. Šema ima četiri nivoa konfigurisanja (od 0 do 3). Nivoe čine funkcionalne oblasti: 0 – Upravljanje odnosom sa korisnikom, 1 – Upravljanje operativom servisa, 2 – Upravljanje operativom resursa, 3 – Upravljanje odnosom sa dobavljačem partnerom. Višenivovsko fazno konfigurisanje po ovoj šemi obezbeđuje automatizovano krojenje modela karakteristika za proces Obračun. MK su izgrađeni 109 kroz proces horizontalnog višenivovskog faznog konfigurisanja. VVFK proces se odvija kroz sledeći redosled aktivnosti: Ručno konfigurisanje MK Faktura za proizvod Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je MK Faktura za proizvod iz koga se kreira ručno konfiguracija Faktura za proizvod. Automatsko krojenje (specijalizacija) MK Obračun za servis Na Nivou 1 – Upravljanje operativom servisa, postavlja se početni MK Obračun za servis. Automatskom specijalizacijom MK Obračun za servis koja se radi primenom konfiguracije Faktura za proizvod dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Obračun za servis. Suštinsko značenje ovoga je automatska transformacija poddomena Faktura za proizvod u poddomen Obračun za servis gde Faktura za proizvod predstavlja specifikaciju a Obračun za servis njegovu realizaciju. Ručno konfigurisanje MK Obračun za servis Na Nivou 1 - Upravljanje operativom servisa, iz skrojenog MK Obračun za servis kreira se ručno konfiguracija Obračun za servis. Automatsko krojenje (specijalizacija) MK Obračun za resurs Na Nivou 2 – Upravljanje operativom resursa, postavlja se početni MK Obračun za resurs. Automatskom specijalizacijom MK Obračun za resurs koja se radi primenom konfiguracije Obračun za servis dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Obračun za resurs. Suštinsko značenje ovoga je automatska transformacija poddomena Obračun za servis u poddomen Obračun za resurs gde Obračun za servis predstavlja specifikaciju a Obračun za resurs njegovu realizaciju. HP Nivo 0 Upravljanje odnosom sa Korisnikom HP Nivo 1 Upravljanje operativom Servisa HP Nivo 2 Upravljanje operativom Resursa HP Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Slika 4.20. Obračun. Faktura za Proizvod Obračun za Servis Obračun za Resurs Prebijanje Obračuna sa D/P 110 Višenivovsko konfigurisanje za Klasu procesa «Obračun» Nivo 0 Upravljanje odnosom sa Korisnikom Nivo 1 Upravljanje operativom Servisa Nivo 2 Upravljanje operativom Resursa Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Nivo 0 – MK Faktura za Proizvod Nivo 0 Konfiguracija Fakture za Proizvod Nivo 1 - MK Obračun za Servis Nivo 1 – MK Specijalizacija Obračuna za Servis Proces Specijalizacije Obračuna za Servis Nivo 1 Konfiguracija Obračuna za Servis Nivo 2 - MK Obračun za Resurs Nivo 2 – MK Specijalizacija Obračuna za Resurs Proces Specijalizacije Obračuna za Resurs Proces Konfigurisanja Fakture za Proizvod Proces Konfigurisanja Obračuna za Servis Nivo 2 Konfiguracija Obračuna za Resurs Proces Konfigurisanja Obračuna za Resurs Nivo 3 - MK Prebijanje Obračuna sa D/P Nivo 3 – MK Specijalizacija Prebijanja Obračuna sa D/P Nivo 3 Konfiguracija Prebijanja Obračuna sa D/P Proces Konfigurisanja Prebijanja Obračuna sa D/P Proces Specijalizacije Prebijanja Obračuna sa D/P Faza 0 Faza 1 Faza 2 Faza 3 Slika 4.21. Vertikalno višenivovsko konfigurisanje klase procesa „Obračun“. 111 Ručno konfigurisanje MK Obračun za resurs Na Nivou 2 - Upravljanje operativom resurs, iz skrojenog MK Obračun za resurs kreira se ručno konfiguracija Obračun za resurs. Automatsko krojenje (specijalizacija) MK Prebijanje obračuna sa D/P Na Nivou 3 – Upravljanje odnosom sa D/P, postavlja se početni MK Prebijanje obračuna sa D/P. Automatskom specijalizacijom MK Prebijanje obračuna sa D/P koja se radi primenom konfiguracije Obračun za resurs dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Prebijanje obračuna sa D/P. Suštinsko značenje ovoga je automatska transformacija poddomena Obračun za resurs u poddomen Prebijanje obračuna sa D/P gde Obračun za resurs predstavlja specifikaciju a Prebijanje obračuna sa D/P njegovu realizaciju. Ručno konfigurisanje MK Prebijanje obračuna sa D/P Na Nivou 3 - Upravljanje odnosom sa D/P, iz skrojenog MK Prebijanje obračuna sa D/P kreira se ručno konfiguracija Prebijanje obračuna sa D/P. 4.1.2.7. VERTIKALNO VIŠENIVOVSKO KONFIGURISANJE KLASE PROCESA „OBEZBEĐENJE PRIHODA“ Na Slici 4.22. prikazuju se osnovni poddomeni Vertikalne grupe procesa Obezbeđenje prihoda. Na Slici su jasno date zavisnosti između poddomena (zavisnosti su odozgo na dole:) Slika 4.22. sa prikazanim među zavisnostima poddomena je osnov da se definiše Šema za VVFK modela karakteristika za vertikalnu klasu procesa Obezbeđenje prihoda. Istovremeno na slici se vide i nazivi horizontalnih procesa kojima poddomeni pripadaju. VVFK šema se dobija kada se osnovni mehanizam za višenivovsko fazno konfigurisanje primeni uzastopno više puta u skladu sa brojem poddomena i njihovim među zavisnostima unutar klase vertikalnog procesa. 112 112 Na Slici 4.23. prikazana je Šema za vertikalno višenivovsko fazno konfigurisanje za klasu procesa Obezbeđenje prihoda. Šema ima četiri nivoa konfigurisanja (od 0 do 3). Nivoe čine funkcionalne oblasti: 0 – Upravljanje odnosom sa korisnikom, 1 – Upravljanje operativom servisa, 2 – Upravljanje operativom resursa, 3 – Upravljanje odnosom sa dobavljačem partnerom. Višenivovsko fazno konfigurisanje po ovoj šemi obezbeđuje automatizovano krojenje modela karakteristika za proces Obezbeđenje prihoda. MK su izgrađeni kroz proces horizontalnog višenivovskog faznog konfigurisanja. VVFK proces se odvija kroz sledeći redosled aktivnosti: Ručno konfigurisanje MK Uplata za fakturu Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je MK Uplata za fakturu iz koga se kreira ručno konfiguracija Uplata za fakturu. Automatsko krojenje (specijalizacija) MK Uplata za servis Na Nivou 1 – Upravljanje operativom servisa, postavlja se početni MK Uplata za servis. Automatskom specijalizacijom MK Uplata za servis koja se radi primenom konfiguracije Uplata za fakturu dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Uplata za servis. Suštinsko značenje ovoga je automatska transformacija poddomena Uplata za fakturu u poddomen Uplata za servis gde Uplata za fakturu predstavlja specifikaciju a Uplata za servis njegovu realizaciju. Ručno konfigurisanje MK Uplata za servis Na Nivou 1 - Upravljanje operativom servisa, iz skrojenog MK Uplata za servis kreira se ručno konfiguracija Uplata za servis. HP Nivo 0 Upravljanje odnosom sa Korisnikom HP Nivo 1 Upravljanje operativom Servisa HP Nivo 2 Upravljanje operativom Resursa HP Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Slika 4.22. Obezbeđenje prihoda. Uplata za Fakturu Uplata za Servis Uplata za Resurs (Prepaid) Uplate/Isplate D/P 113 Višenivovsko konfigurisanje za Klasu procesa «Obezbeđenje prihoda» Nivo 0 Upravljanje odnosom sa Korisnikom Nivo 1 Upravljanje operativom Servisa Nivo 2 Upravljanje operativom Resursa Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Nivo 0 – MK Uplata za Fakturu Nivo 0 Konfiguracija Uplate za Fakturu Nivo 1 - MK Uplata za Servis Nivo 1 – MK Specijalizacija Uplate za Servis Proces Specijalizacije Uplate za Servis Nivo 1 Konfiguracija Uplate za Servis Nivo 2 - MK Uplata za Resurs Nivo 2 – MK Specijalizacija Uplate za Resurs Proces Specijalizacije Uplate za Resurs Proces Konfigurisanja Uplate za Fakturu Proces Konfigurisanja Uplate za Servis Nivo 2 Konfiguracija Uplate za Resurs Proces Konfigurisanja Uplate za Resurs Nivo 3 - MK Uplate/Isplate D/P Nivo 3 – MK Specijalizacija Uplate/Isplate D/P Nivo 3 Konfiguracija Uplate/Isplate D/P Proces Konfigurisanja Uplate/ Isplate D/P Proces Specijalizacije Uplate/ Isplate D/P Faza 0 Faza 1 Faza 2 Faza 3 Slika 4.23. Vertikalno višenivovsko konfigurisanje klase procesa „Obezbeđenje prihoda 114 Automatsko krojenje (specijalizacija) MK Uplata za resurs Na Nivou 2 – Upravljanje operativom resursa, postavlja se početni MK Uplata za resurs. Automatskom specijalizacijom MK Uplata za resurs koja se radi primenom konfiguracije Uplata za servis dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Uplata za resurs. Suštinsko značenje ovoga je automatska transformacija poddomena Uplata za servis u poddomen Uplata za resurs gde Uplata za servis predstavlja specifikaciju a Uplata za resurs njegovu realizaciju. Ručno konfigurisanje MK Uplata za resurs Na Nivou 2 - Upravljanje operativom resurs, iz skrojenog MK Uplata za resurs kreira se ručno konfiguracija Uplata za resurs. Automatsko krojenje (specijalizacija) MK Uplate/Isplate D/P Na Nivou 3 – Upravljanje odnosom sa D/P, postavlja se početni MK Uplate/Isplate D/P. Automatskom specijalizacijom MK Uplate/Isplate D/P koja se radi primenom konfiguracije Uplata za resurs dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Uplate/Isplate D/P. Suštinsko značenje ovoga je automatska transformacija poddomena Uplata za resurs u poddomen Uplate/Isplate D/P gde Uplata za resurs predstavlja specifikaciju a Uplate/Isplate D/P njegovu realizaciju. Ručno konfigurisanje MK Uplate/Isplate D/P Na Nivou 3 - Upravljanje odnosom sa D/P, iz skrojenog MK Uplate/Isplate D/P kreira se ručno konfiguracija Uplate/Isplate D/P. 4.1.3. DEFINISANJE SISTEMA ZA GENERISANJE MODELA Modeli karakteristika lepo predstavljaju zajedničke i različite karakteristike familije proizvoda. Međutim modeli karakteristika nisu sami sebi svrha. Oni predstavljaju vodilju za izradu modela koji specificiraju podatke ili ponašanje nekog domena. To znači da modeli karakteristika treba da se preslikavaju u druge modele i da na njih prenesu potrebnu semantiku. Preslikavanje MK u druge modele se radi preko mehanizma za generisanje modela. 115 4.1.3.1. DEFINISANJE OSNOVNOG MEHANIZMA ZA GENERISANJE MODELA U radu [CzaAn 2005] autori definišu mehanizam za generisanje modela. Naime Model Familije proizvoda može da se predstavi kao Model karakteristika i Model šablona (Model template). Modeli karakteristika definišu hijerarhiju karakteristika zajedno sa ograničenjima njihovih mogućih konfiguracija. Šablon modela sadrži uniju elemenata modela u svim oblicima validnih instanci šablona. Skup validnih instanci šablona modela odgovara granicama familije modela. Šablon modela je sam po sebi model iskazan u istoj ciljnoj notaciji kao i instance šablona. Između modela karakteristika i šablona modela definišu se oznake (anotacije). Oznake se definišu kao karakteristike ili atributi karakteristika modela karakteristika koji u zavisnosti izabrane konfiguracije uključuju ili isključuju elemente šablona modela. Instanca familije modela se specificira kreiranjem konfiguracije modela karakteristika, na osnovu koje se automatski instancira šablon modela. Proces instanciranja predstavlja Model-Model transformaciju. U ovoj tezi definisan je mehanizam za generisanje UML modela klasa koji je u suštini zasnovan na ideji iz [CzaAn 2005]. Ova ideja može da se poboljša ako se iskoristi način definisanja i instanciranja šablona modela koji se daje u knjizi [Souza 1998], gde se šabloni modela predstavljaju kao UML generički modeli a njihove instance kao UML modeli. To znači da šabloni modela nisu iskazani kao unija svih instanci koje se zatim u zavisnosti od konfiguracije modela karakteristika samo uključuju ili isključuju čime se dobija konkretan model. Ovde se šablon modela predstavlja kao UML šablon čiji elementi su označeni sa uglastim zagradama (na primer < Ime servisa >) gde se konkretna instanca generiše pisanjem naziva u uglastim zagradama (na primer IPTV servis). Na Slici 4.24. prikazan je Mehanizam koji omogućava generisanje Modela na osnovu Konfiguracije modela karakteristika i šablona modela. Na nivou N (N>0) definiše se MK na osnovu koga se manuelno pravi Konfiguracija (nivo N). Na nivou N definiše se Šablon modela. Šabloni modela mogu da budu Šabloni modela podataka ili Šabloni modela ponašanja. U ovoj tezi koristiće se samo Šabloni modela podataka. Korišćenje i šablona drugih modela bi znatno učinilo tezu obimnijom 116 (Principi su isti i kod jednih i kod drugih modela). Karakteristike MK sa i elementi Šablona modela su međusobno označeni (anotirani). Na osnovu: Konfiguracije MK sa nivoa N, Šablona modela sa nivoa N i međusobno označenih elemenata Algoritam za automatsko instanciranje šablona modela generiše Model (instance šablona) na nivou N. Templejt Modela Nivo N Model Karakteristika Nivo N Konfiguracija Nivo N Nivo N Osnovni mehanizam za generisanje modela Označene karakteristike Instanca Templejta modela Nivo N N >= 0 Automatsko Instanciranje templejta na Nivou N Slika 4.24. Osnovni mehanizam za generisanje modela. Kada se ovako definisan mehanizam za generisanje modela ugradi u već definisane šeme za vertikalno višenivovsko fazno konfigurisanja dobije se čitav sistem za generisanje modela (Slika 4.25). 4.1.3.2. SISTEM ZAVIŠENIVOVSKO GENERISANJE MODELA ZA KLASU PROCESA - RAZVOJ PROIZVODA Sistem za vertikalno višenivovsko fazno konfigurisanje se realizuje preko šest šema (prethodno je ceo sistem detaljno opisan). U svakoj šemi na svakom nivou gde god je predviđeno postojanje konfiguracije modela karakteristika dodaje se mehanizam za automatsko generisanje modela. Skup ovako dopunjenih šema sa novim mehanizmima formira Sistem za višenivovsko generisanje modela Na Slici 4.25. prikazana je Šema za vertikalno višenivovsko fazno konfigurisanje za klasu procesa Razvoj proizvoda gde je na svakom nivou gde postoji konfiguracija dodata mehanizam za generisanje modela. Višenivovsko fazno konfigurisanje po ovoj 117 Nivo 0 Upravljanje odnosom sa Korisnikom Nivo 1 Upravljanje operativom Servisa Nivo 2 Upravljanje operativom Resursa Nivo 3 Upravljanje Odnosom sa Dobavljačem/Partnerom Nivo 0 – MK Specifikacija Proizvoda Nivo 0 Konfiguracija Specifikacije Proizvoda Nivo 1 - MK Specifikacija Servisa Nivo 1 – MK Specijalizacija Specifikacije Servisa Nivo 1 Konfiguracija Speciikacije Servisa Nivo 2 - MK Specifikacija Resursa Nivo 2 – MK Specijalizacija SpecifikacijE Resursa Nivo 2 Konfiguracija Specifikacije Resursa Nivo 3 - MK Specifikacija Resursa D/P Nivo 3 – MK Specijalizacija Specifikacija Resursa D/P Nivo 3 Konfiguracija Specifikacije Resursa D/P Nivo 0 Templejt modela Specifikacija Proizvoda Nivo 0 Instanca templejta modela Specifikacija Proizvoda Nivo 1 Templejt modela Specifikacija Servisa Nivo 1 Instanca templejta modela Specifikacija Servisa Nivo 2 Templejt modela Specifikacija Resursa Nivo 2 Instanca templejta modela Specifikacija Resursa Nivo 3 Templejt modela Specifikacija Resursa D/P Nivo 3 Instanca templejta modela Specifikacija Resursa D/P P ro ce s In stan ciran ja te m p le jta m o d e la Sp e cifikacija P ro izvo d a Pro ce s In stan ciran ja te m p le jta m o d e la Sp e cifikacija Se rvisa P ro ce s In stan ciran ja te m p le jta m o d e la Sp e cifikacija R e su rsa Proces Instanciranja templejta modela Specifikacija Resursa D/P Slika 4.25. Sistem za Višenivovsko Generisanje modela za klasu procesa - Razvoj proizvoda. 118 šemi obezbeđuje automatizovano krojenje modela karakteristika, izrada konfiguracija tih MK i automatsko generisanje modela na osnovu šablona modela i pomenutih konfiguracija. Funkcionisanje ovako napravljenog sistema se odvija sledećim redosledom: Ručno konfigurisanje MK Specifikacija proizvoda Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je MK Specifikacija proizvoda iz koga se kreira ručno konfiguracija Specifikacija proizvoda. Automatsko generisanje modela Specifikacija proizvoda Na Nivou 0 – Upravljanje odnosom sa korisnikom postavljen je Šablon modela Specifikacija proizvoda. Automatskim instanciranjem Šablona modela Specifikacija proizvoda na osnovu konfiguracije Specifikacija proizvoda generiše se Model Specifikacija proizvoda. Automatsko krojenje (specijalizacija) MK Specifikacija servisa Na Nivou 1 – Upravljanje operativom servisa, postavlja se početni MK Specifikacija servisa. Automatskom specijalizacijom MK Specifikacija servisa koja se radi primenom konfiguracije Specifikacije proizvoda dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Specifikacija servisa. Suštinsko značenje ovoga je automatska transformacija koncepta Proizvod u koncept Servis gde Proizvod predstavlja specifikaciju a Servis njegovu realizaciju. Ručno konfigurisanje MK Specifikacija servisa Na Nivou 1 - Upravljanje operativom servisa, iz skrojenog MK Specifikacija servisa kreira se ručno konfiguracija Specifikacija servisa. Automatsko generisanje modela Specifikacija proizvoda Na Nivou 1 – Upravljanje operativom servisa postavljen je Šablon modela Specifikacija servisa. Automatskim instanciranjem Šablona modela Specifikacija servisa na osnovu konfiguracije Specifikacija servisa generiše se Model Specifikacija servisa. Automatsko krojenje (specijalizacija) MK Specifikacija resursa Na Nivou 2 – Upravljanje operativom resursa, postavlja se početni MK Specifikacija resursa. Automatskom specijalizacijom MK Specifikacija resursa koja se radi primenom 119 konfiguracije Specifikacije servisa dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Specifikacija resursa. Suštinsko značenje ovoga je automatska transformacija koncepta Servis u koncept Resurs gde Servis predstavlja specifikaciju a Resurs njegovu realizaciju. Ručno konfigurisanje MK Specifikacija resursa Na Nivou 2 - Upravljanje operativom resursa, iz skrojenog MK Specifikacija resursa kreira se ručno konfiguracija Specifikacija resursa. Na Nivou 2 – Upravljanje operativom resursa postavljen je Šablon modela Specifikacija resursa. Automatskim instanciranjem Šablona modela Specifikacija resursa na osnovu konfiguracije Specifikacija resursa generiše se Model Specifikacija resursa. Automatsko krojenje (specijalizacija) MK Specifikacija resursa za D/P Na Nivou 3 – Upravljanje odnosom sa D/P, postavlja se početni MK Specifikacija resursa D/P. Automatskom specijalizacijom MK Specifikacija resursa D/P koja se radi primenom konfiguracije Specifikacije resursa dobija se specijalizovani (skrojen prema konfiguraciji sa višeg nivoa) MK Specifikacija resursa D/P. Suštinsko značenje ovoga je automatska transformacija koncepta Resurs u koncept Resurs D/P gde Resurs predstavlja specifikaciju a Resurs D/P njegovu realizaciju. Ručno konfigurisanje MK Specifikacija resursa D/P Na Nivou 3 - Upravljanje odnosom sa D/P, iz skrojenog MK Specifikacija resursa D/P kreira se ručno konfiguracija Specifikacija resursa D/P. Na Nivou 3 – Upravljanje operativom resursa D/P postavljen je Šablon modela Specifikacija resursa D/P. Automatskim instanciranjem Šablona modela Specifikacija resursa D/P na osnovu konfiguracije Specifikacija resursa D/P generiše se Model Specifikacija resursa D/P. Na sličan način mehanizam za generisanje modela je ugrađen i u ostale šeme za višenivovsko fazno konfigurisanje. 120 U nastavku sledi prikaz šablona nekoliko karakterističnih modela. Polazna osnova za definisanje ovih modela je znanje uzeto iz industrijskog standard za oblast telekomunikacija NGOSS – SID i konkretnog informacionog sistema TIS. 4.1.3.3. DEFINISANJE ŠABLONA UML MODELA KLASA – SPECIFIKACIJA PROIZVODA Na Slici 4.26. prikazan je Šablon UML modela dijagrama klasa - Specifikacija proizvoda. Nazivi UML klasa na dijagramu su u uglastim zagradama, na primer , što znači da je naziv šablon i da može da se zameni sa konkretnom instancom šablona, na primer IPTV. Ova sintaksa za prikaz šablona uzeta je iz knjige [Souza 1998]. -SifraProizvoda : Integer -NazivProizvoda : String 1 * -OpisPaketa : String -OpisPojedinacnogProizvoda : String -SifraFunkcionalnosti : Integer -NazivFunkcionalnosti : String 0..1 * -OpisFunkcionalnosti : String -SifraKarakteristike : Integer -NazivKarakteristike : String Slika 4.26. Šablon UML modela klasa – Specifikacija proizvoda. Šablon UML modela klasa ima sledeću semantiku. je neki proizvod koji se prodaje od strane telekom operatora. Može da se specijalizuje u ili u se sastoji od jedne ili više . mogu da se dalje specijalizuju kroz . Pored toga svaki ima jednu ili više , koje mogu da se dalje specijalizuju . 121 Kod instanciranja ovog šablona pojedini delovi šablona kao što su i mogu da se instanciraju više puta. Instanciranjem šablona na ovaj način mogu da se generišu proizvodi sa veoma različitim funkcionalnostima i karakteristikama. 4.1.3.4. DEFINISANJE ŠABLONA UML MODELA KLASA – SPECIFIKACIJA SERVISA Na Slici 4.27. prikazan je Šablon UML modela dijagrama klasa - Specifikacija servisa, koji je po strukturi veoma sličan prethodno opisanom šablonu. Ovaj šablon definiše pogled korisnika na servisa (Customer Facing Service prema NGOSS – SID). -SifraServisa : Integer -NazivServisa : String 1 * -OpisPaketaServisa : String -OpisOsnovnogServisa : String -SifraAtomskogServisa : Integer -NazivAtomskogServisa : String 0..1 * -OpisAtomskogServisa : String -SifraServisaResursa : Integer -NazivServisaResursa : String 0..1 * -OpisServisaResursa : String Slika 4.27. Šablon UML modela klasa – Specifikacija Servisa. Šablon UML modela klasa na Slici 4.27. ima sledeću semantiku. je neki servis koji se pruža od strane telekom operatora. Može da se specijalizuje u ili u koji se dobija agregacijom više pojedinačnih servisa. se sastoji od jednog ili više . može da se dalje specijalizuje u . Pored toga svaki ima jedan ili više preko koga se realizuje, koji mogu da se dalje specijalizuju u . 122 Kod instanciranja ovog šablona pojedini delovi šablona kao što su i mogu da se instanciraju više puta. Instanciranjem šablona na ovaj način mogu da se generišu različiti servisi koji se sastoje iz različitih atomskih servisa i koji mogu da se realizuju preko različitih resursa. 4.1.3.5. DEFINISANJE ŠABLONA UML MODELA KLASA – SPECIFIKACIJA RESURSA Na Slici 4.28. prikazan je Šablon UML modela dijagrama klasa - Specifikacija resursa, koji je nešto složeniji nego što su to prethodno opisani šabloni. Ovaj šablon definiše pogled sa strane resursa na servis koji predstavlja tehnički pogled (Resource Facing Service prema NGOSS – SID). Šablon UML modela klasa na Slici 4.28. ima sledeću semantiku. su neki resursi telekom operatora preko kojih se realizuju servisi. Ova klasa može da se specijalizuje u ili u koji se dobija agregacijom više pojedinačnih servisa sa strane resursa. Klasa agregira nula, jedan ili više klasa . Klasa predstavlja specijalizaciju klase . je takođe specijalizacija klase Resurs i gradi se agregacijom više atomskih resursa. Klasa može da se dalje specijalizuje u klase , , . Klasa se dalje specijalizuje u , a ova dalje u . Klasa se dalje specijalizuje u , a ova dalje u . Klasa se dalje specijalizuje u , a ova dalje u . 123 -SifraServisa : Integer -NazivServisa : String 1 * -OpisPaketaServisa : String -SifraResursa : Integer -NazivResursa : String 1 * -OpisSloženogResursa : String -OpisAutomskogResursa : String -OpisResursa : String -OpisResursa : String -OpisResursa : String 0..1 * Slika 4.28. Šablon UML modela klasa – Specifikacija Resursa. 124 Kod instanciranja ovog šablona pojedini delovi šablona kao što je može da se instancira više puta. Instanciranjem šablona na ovaj način mogu da se generišu različiti modeli različitih veličina. 4.1.4. TESTIRANJE SISTEMA Testiranje kod SPL pristupa se razlikuje od testiranja pojedinačnih aplikacija gde su rukotvorine za testiranje validne samo za tu aplikaciju. Kod domenskog inženjerstva rukotvorine za testiranje se mogu ponovo koristiti. One se moraju sastojati iz zajedničkog i varijabilnog dela Kod domenskog inženjerstva se definiše generički test plan. Test plan se odnosi na raspoložive varijante i ponovo se koristi da proizvede test plan za pojedinačne aplikacije. Rukotvorine za testiranje opšteg domenskog inženjerstva za telekomunikacioni domen su:  Testiranje sistema za Horizontalno Višenivovsko Fazno Konfigurisanje,  Testiranje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje,  Testiranje sistema za Generisanje Modela Ove rukotvorine su generičke za testiranje u domenskom inženjerstvu za tip servisa U knjizi [PoBoLi 2005] je više pažnje posvećenu testiranju u SPL. U ovoj nije dat fokus na fazu testiranja, pa se ona zato i oslanja na način testiranja koji je dat u pomenutoj knjizi. 125 4.2. DETALJNI OPIS DOMENSKOG INŽENJERINGA TELEKOMUNIKACIONOG DOMENA ZA TIP SERVISA Kao što je već navedeno u poglavlju tri osnovni koraci domenskog inženjeringa za tip servisa su:  Uvođenje novog Tipa servisa (PLM – Obuhvat za Tip servisa).  Definisanje Modela u sistemu za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) za Tip Servisa.  Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) za Tip Servisa.  Definisanje sistema za Generisanje modela za Tip Servisa.  Testiranje sistema za Tip Servisa. 4.2.1. DEFINISANJE MODELA U SISTEMU ZA HORIZONTALNO VIŠENIVOVSKO FAZNO KONFIGURISANJE (HVFK) ZA „IPTV“ TIP SERVISA Sistem za horizontalno višenivovsko fazno konfigurisanje (HVFK) za tip servisa ima zadatak da kontrolisano (obezbeđuje poštovanje horizontalnih međuzavisnosti poddomena) i sveobuhvatno (obuhvata sve poddomene svih funkcionalnih oblasti) definiše sve početne Modele karakteristika po funkcionalnim oblastima telekomunikacionog domena (za IPTV servis). Na Slici 4.29. su definisani osnovni koraci ovog sistema:  Definisanje Modela karakteristika u Šemi HVFK za poddomen Upravljanje odnosom sa korisnikom;  Definisanje Modela karakteristika u Šemi HVFK za poddomen Upravljanje operativom servisa;  Definisanje Modela karakteristika u Šemi HVFK za poddomen Upravljanje operativom resursa; 126 Definisanje Modela karakteristika za poddomen Upravljanje odnosom sa korisnikom Definisanje Modela karakteristika za poddomen Upravljanje operativom servisa Definisanje Modela karakteristika za poddomen Upravljanje operativom resursa Definisanje Modela karakteristika za poddomen Upravljanje odnosom sa Dobavljačem/Partnerom Šema HVFK za poddomen Upravljanje odnosom sa korisnikom Šema HVFK za poddomen Upravljanje operativom servisa Šema HVFK za poddomen Upravljanje operativom resursa Šema HVFK za poddomen Upravljanje odnosom sa Dobavljačem/Partnerom D O M EN IN ŽE N JE R IN G Z A T IP S ER V IS A In že n je rs tv o d o m en sk ih za h te va D iz aj n d o m en a R ea liz ac ija d o m en a Te st ir an je d o m en a Modeli karakteristika za poddomen Upravljanje odnosom sa korisnikom Modeli karakteristika za poddomen Upravljanje operativom servisa Modeli karakteristika za poddomen Upravljanje operativom resursa Modeli karakteristika za poddomen Upravljanje odnosom sa Dobavljačem/Partnerom Šeme VVFK sistema za generisanje IS za Tip servisa Modeli Karakteristika za funkcionalne poddomene za Tip servisa TIS Definisanje sistema za Generisanje IS za Tip Servisa Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) za Tip Servisa Definisanje Modela u sistemu za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) za Tip Servisa Šabloni UML modela i koda Tip servisa Uvođenje novog Tipa servisa (PLM – Obuhvat za Tip servisa) Šeme VVFK sistema za Tip servisa (anotacije karakteristika) Testiranje sistema za Tip Servisa Testovi HVFK, VVFK, IS Šeme i mehanizmi HVFK sistema Šeme i mehanizmi VVFK sistema Šeme HVFK sistema za Tip servisa Šeme i mehanizmi za generisanje modela (GM) Slika 4.29. Domenski inženjering – Definisanje HVFK sistema za Tip servisa. 127  Definisanje Modela karakteristika u Šemi HVFK za poddomen Upravljanje odnosom sa Dobavljačem/Partnerom Sistem za Horizontalno Višenivovsko Fazno konfigurisanje za IPTV tip servisa se realizuje u četiri HVFK šeme. Šeme su prethodno izgrađene i predstavljaju ljušturu u koju je potrebno sada ugraditi modele za u ovom slučaju IPTV tip servisa. Kako se ne bi ponavljali ovde će se samo dati primer kreiranja dva modela karakteristika a ostali modeli će se detaljnije prikazati kod šema za vertikalno višenivovsko konfigurisanje. Na Slici 4.30. dat je Modela karakteristika koji u Šemi HVFK za poddomen Upravljanje odnosom sa korisnikom pripada i vertikalnom procesu Ispunjenje (Realizacija). MK koji se zove MK Specifikacija proizvoda za nuđenje u ovoj šemi horizontalno zavisi od MK Specifikacija proizvoda i iz njega se izvodi MK Specifikacija proizvoda je početni MK za celu funkcionalnu oblast Upravljanje odnosom sa korisnikom. Opisan je još u poglavlju dva. Na Slici 4.30. karakteristike označene narandžastom bojom pripadaju ovom MK. Suština ovog MK je da on definiše sve bitne funkcionalne karakteristike (funkcionalnosti) IPTV proizvoda onako kako ih vidi korisnik: TV Program, Video na zahtev, Snimanje sadržaja, itd. Neke od ovih funkcionalnosti su obavezne a druge mogu da se izaberu, konfigurišu od strane korisnika. MK Specifikacija proizvoda za nuđenje se definiše na osnovu MK Specifikacija proizvoda koja predstavlja uzor (pattern). Iz MK Specifikacija proizvoda napravi se konfiguracija karakteristika koja se zatim prevede automatski u novi suženi MK Specifikacija proizvoda. MK Specifikacija proizvoda za nuđenje se gradi tako što se izabrana MK Specifikacija proizvoda dopunjava sa karakteristikama koje se odnose na cene a koje se vezuju za karakteristike koje se odnose na funkcionalnosti. Na Slici 4.30. zelenom bojom su obeležene nove karakteristike. Za IPTV proizvod za nuđenje uvedena je Osnovna pretplata, Popust i Bonus koje važe u suštini za zajedničke i obavezne funkcionalnosti IPTV-a. Za neobavezne funkcionalnosti uvode se nove karakteristike: Pretplata za dodatne kanale, Cena filma kod iznajmljivanja na zahtev, 128 . TV Program Rezolucija slike Način pristupa Fiksna linija Bežično Standardna definicija Visoka definicija Specifikacija proizvoda za nuđenje - IPTV MK – Specifikacija Proizvoda za nudjenje Nivo 0, Faza 0 Video na Zahtev Snimanje sadržaja Gledanje IPTV Na dva mestaNa jednom mestu LokalnoCentralnoDodatni TV kanaliOsnovni TV kanali [1..2] [1..2] [1..2] [1..1] Pretplata za Dodatne TV kanale Cena filma Instalaciona taksa Cena dogradnjeCena dodatne opreme Cena za opremu za snimanje Cena čuvanja sadržaja Cena opreme Osnovna pretplata Popust Bonus Dodatna pretplata za drugi TV [0..2] [0..2] Slika 4.30. Specifikacija modela karakteristika Proizvoda za nuđenje na osnovu MK Specifikacija proizvoda. 129 TV Program Problemi Rezolucija slike Problemi Problemi pristupa Fiksna linija Problemi Bežično Problemi Problemi proizvoda - IPTV MK – Specifikacija Problema Proizvoda Nivo 0, Faza 0 Video na Zahtev Ne radi Snimanje sadržaja Ne radi Gledanje IPTV Problemi Problemi Na dva mesta Problemi Na jednom mestu Lokalno Ne radi Centralno Ne radi Dodatni TV kanali Problemi Osnovni TV kanali Problemi [1..2] [1..2] [1..3] [1..*] [1..6] Seckanje slike Ne prolazi do servera Crna slika [1..2] [1..2] Visoka definicija Loša slika Standardna definicija Zamrznuta slika Slika 4.31. Specifikacija modela karakteristika Proizvoda za nuđenje na osnovu MK Specifikacija proizvoda. 130 Cena čuvanja sadržaja na centralnoj platformi, Cena opreme za lokalno snimanje, Dodatna pretplata za korišćenje IPTV sadržaja na drugom mestu, Cena dodatne opreme, Instalaciona taksa za uvođenje fiksne linije, Cena dogradnje fiksne linije. Prethodno je definisan MK kada je prethodni MK korišćen delom ili u celini kao uzor, skelet, podloga za dalje definisanje novog MK. Na Slici 4.31. daje se MK Problemi proizvoda – IPTV koji je definisan koristeći isti početni MK kao polazni ali na malo drugačiji način. Naime početni MK je ovde više korišćen kao šablon, kopirane su sve bitne karakteristike početnog MK, pa su onda dorađene izmenom naziva karakteristika. MK Problemi proizvoda – IPTV definiše probleme koji nastaju kod lošeg rada IPTV funkcionalnosti: TV program ima probleme, Osnovni kanali imaju problem, Dodatni kanali imaju problem, Video na zahtev ne radi, Snimanje sadržaja ne radi, Loša slika, Zamrznuta slika, Crna slika, Seckanje slike, Nema prolaza do servera, itd. Prethodno je ilustrovan razvoj dva modela karakteristika koji su međusobno zavisni. Svi MK koji su definisani u sve četiri šeme za horizontalno višenivovsko konfigurisanje su izrađene na sličan način. Da se ne bi duplirao njihov opis jedan deo ovih model će biti opisan u nastavku u delu koji se odnosi na vertikalno višenivovsko fazno konfigurisanje. 4.2.2. DEFINISANJE SISTEMA ZA VERTIKALNO VIŠENIVOVSKO FAZNO KONFIGURISANJE (VVFK) ZA IPTV TIP SERVISA Sistem za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) za IPTV tip servisa se realizuje kroz šest šema (Slika 4.32.). Glavni rezultat izvršenja vertikalne višenivovske fazne konfiguracije je realizacija razvoja vertikalnih procesa za IPTV tip servisa kroz višenivovsku faznu transformaciju Modela karakteristika gde rezultat (konfiguracija) sa prethodnog nivoa predstavlja ulazne parametre za izradu modela karakteristika na donjem nivou. VVFK sistem za IPTV tip servisa funkcioniše kroz sledeće korake:  Definisanje Šema VVFK za klasu procesa Razvoj proizvoda sa ugrađenim MK njihovim anotacijama; 131 D O M EN IN ŽE N JE R IN G Z A T IP S ER V IS A In že n je rs tv o d o m en sk ih za h te va D iz aj n d o m en a R ea liz ac ija d o m en a Te st ir an je d o m en a Definisanje sistema za VVFK za klasu procesa Razvoj Proizvoda – za Tip servisa Definisanje sistema za VVFK za klasu procesa Ispunjenje (Realizacija) – za Tip servisa Definisanje sistema za VVFK za klasu procesa Obezbeđenje održavanja – za Tip servisa Definisanje sistema za VVFK za klasu procesa Obezbeđenje kvaliteta – za Tip servisa Šema VVFK za klasu procesa Razvoj proizvoda sa MK i anotacijama Šema VVFK za klasu procesa Ispunjenje (Realizacija) sa MK i anotacijama Šema VVFK za klasu procesa Obezbeđenje održavanja sa MK i anotacijama Šema VVFK za klasu procesa Obezbeđenje kvaliteta sa MK i anotacijama Definisanje sistema za VVFK za klasu procesa Obezbeđenje prihoda – za Tip servisa Definisanje sistema za VVFK za klasu procesa Obračun – za Tip servisa Šema VVFK za klasu procesa Obračun sa MK i anotacijama Šema VVFK za klasu procesa Obezbeđenje prihoda sa MK i anotacijama Šema VVFK za klasu procesa Razvoj proizvoda Šema VVFK za klasu procesa Ispunjenje (Realizacija) Šema VVFK za klasu procesa Obezbeđenje održavanja Šema VVFK za klasu procesa Obezbeđenje kvaliteta Šema VVFK za klasu procesa Obračun Šema VVFK za klasu procesa Obezbeđenje prihoda Šeme VVFK sistema za generisanje IS za Tip servisa Modeli Karakteristika za funkcionalne poddomene za Tip servisa TIS Definisanje sistema za Generisanje IS za Tip Servisa Definisanje sistema za Vertikalno Višenivovsko Fazno Konfigurisanje (VVFK) za Tip Servisa Definisanje Modela u sistemu za Horizontalno Višenivovsko Fazno Konfigurisanje (HVFK) za Tip Servisa Šabloni UML modela i koda Tip servisa Uvođenje novog Tipa servisa (PLM – Obuhvat za Tip servisa) Šeme VVFK sistema za Tip servisa (anotacije karakteristika) Testiranje sistema za Tip Servisa Testovi HVFK, VVFK, IS Šeme i mehanizmi HVFK sistema Šeme i mehanizmi VVFK sistema Šeme HVFK sistema za Tip servisa Šeme i mehanizmi za generisanje modela (GM) Slika 4.32. Domenski inženjering – Definisanje VVFK sistema za Tip servisa. 132  Definisanje Šema VVFK za klasu procesa Ispunjenje (Realizacija) sa ugrađenim MK njihovim anotacijama;  Definisanje Šema VVFK za klasu procesa Obezbeđenje održavanja sa ugrađenim MK njihovim anotacijama;  Definisanje Šema VVFK za klasu procesa Obezbeđenje kvaliteta sa ugrađenim MK njihovim anotacijama;  Definisanje Šema VVFK za klasu procesa Obračun sa ugrađenim MK njihovim anotacijama;  Definisanje Šema VVFK za klasu procesa Obezbeđenje prihoda sa ugrađenim MK njihovim anotacijama. 4.2.2.1. DEATALJI OSNOVNOG MEHANIZMA ZA VIŠENIVOVSKO FAZNO KONFIGURISANJE Osnovni mehanizam za višenivovsko fazno konfigurisanje objašnjen je u poglavlju tri. Ovde se daju detalji funkcionisanja algoritma za automatsku specijalizaciju koji je preuzet iz [CzaHeEi 2004]. Automatska specijalizacija modela karakteristika na nivou n se definiše oznakama specijalizacije (anotacijama) koje su vezane za karakteristike tog modela karakteristika. Oznake specijalizacije se sastoje se iz dva elementa:  Uslov, koji je formula Bulove algebre sačinjena od karakteristika modela karakteristika sa nivou n -1, npr. f1∧(f2∨f3); formula se može tumačiti uvažavajući konfiguraciju na nivou n -1: fi je tačno ako karakteristika fi je deo konfiguracije ili je pogrešna ako je drugačije. Tip Specijalizacije, koja je ili negativna, pozitivna, ili kompletna (završena, potpuna); specijalizacija tipa kontroliše koji od koraka specijalizacije iz Tabele 1. se primenjuje na označene karakteristike. U najboljem slučaju, jedna oznaka može biti priključena na jednu karakteristiku i moraju se osigurati da preduslovi Tabele 1. se ne krše. Ovi uslovi pomažu u izbegavanju sukoba tokom specijalizacije, kao što su pokušaji da se ukloni obavezna karakteristika. 133 Tabela 1. Operacije specijalizacije: remove i select. OPERACIJA SPECIJALIZACIJE PREDUSLOV EFEKAT Remove (f,m) f je usamljena karakteristika sa kardinalnošću [0..n] u modelu karakteristika m Profinjavanje kardinalnosti karakteristike f na [0..0] Remove (f,m) f je grupisana karakteristika u grupi sa k karakteristika i kardinalnošću (n1-n2), gde je n10 u modelu karakteristika m Profinjavanje kardinalnosti karakteristike f na [1..n] Select (f,m) f je grupisana karakteristika u grupi sa kardinalnošću (n1-n2), gde je 0>. Proces apstrahovanja/konkretizacije može se primenjivati više puta uzastopno čime se dobija hijerarhija apstrakcija/konkretizacija. Mnogi metodološki pristupi u razvoju softvera su bazirani na ovom procesu. Postoji 210 više načina kako će se obaviti postupak apstrahovanja/konkretizacije. Te načini se nazivaju apstraktni mehanizmi koji se odlikuju specifičnim metodom i relacijom apstrahovanja/konkretizacije. U praksi su to sledeći apstraktni mehanizmi: Klasifikacija/Instanciranje, Generalizacija/Specijalizacija, Agregacija/Dekompozicija, Učaurenje/Realizacija itd. Postoje različiti nivoi apstrakcija i što su one višeg nivoa (veće granularnosti) proces razvoja softvera je produktivniji [GreeWi 2004]. Zbog toga je razvoj i uvođenje apstrakcija što višeg nivoa jedan od načina prevazilaženja problema u razvoju softvera. Istorija razvoja metodoloških pristupa i softverskih tehnologija je ništa drugo nego istorija razvoja apstrakcija kroz uvođenje apstrakcija višeg nivoa i sve veće granularnosti: Semantički modeli, Konceptualni, Ontologije [Dijkstra 1976], [DeMarco 1978], [Neško02 2006]. Značaj apstrakcija može da se pronađe u radu [ZimmKG 2004] gde se citira Grady Boosh “Fundamenti inženjerstva kao što su dobre apstrakcije, dobra separacija problema nikada neće izaći iz mode” i “postoje realne mogućnosti da se podigne nivo apstrakcije ponovo”. U radovima [AtGuKe 2009] i [AtkKeGo 2010] autori opisuju novu vrstu infrastrukture za modelovanje koja je zasnovana na višestrukim ontološkim i lingvističkim klasifikacionim nivoima. Višenivovski jezički inženjering se zasniva na pomenutoj infrastrukturi. Autori takođe diskutuju o glavnim pitanjima jezičkog inženjerstva da bi obezbedili veću jezičku podršku za ontološke i lingvističke klasifikacije: Dualna klasifikacija, Klasa/Objekat dualnost, Duboko klasifikovanje, Uniformni konektor strukture i vizuelizacije, Duboki jezika za ograničenja, Vizuelizacija vođena ontološkom klasifikacijom. U radu [NešCve 2011] daje se pristup zasnovan na višenivovskoj ortogonalnoj i jezičkoj klasifikaciji servisa. Glavni jezički koncept je model karakteristika a ontološke klasifikacije se uzimaju iz ITIL standarda za upravljanje fazama životnog ciklusa servisa. U radu je predložena višenivovska ontološka servisna arhitektura. Kroz ontološke nivoe koje čine modeli karakteristika se silazi tehnikom dubokog instanciranja. Modeli karakteristika predstavljaju zajedničke i različite karakteristike familije proizvoda. Oni nisu sami sebi svrha i oni se preslikavaju u druge modele i na njih 211 prenose potrebnu semantiku. Način preslikavanja MK u druge modele daje se u radu [CzaAn 2005]. U radu [CveNe01 2010] daje se pristup definisanja obuhvata telekomunikacione kompanije preko softverske proizvodne linije. Osnov za definisanja obuhvata je NGOSS standard za industriju telekomunikacija. 5.2. ANALIZA PRISTUPA ZA RAZVOJ IS U ovom poglavlju se analiziraju prednosti i nedostaci prethodno prikazanih metodoloških pristupa korišćenih u tezi. Zatim se prikazuju prednosti i nedostaci novo definisanog Pristupa za razvoj IS telekomunikacione kompanije zasnovanog na modelima. Na kraju poglavlja se daje Slika 5.1. koja predstavlja uporedni pregled prednosti i nedostataka metodoloških pristupa. 5.2.1. PREDNOSTI I NEDOSTACI POSTOJEĆIH PRISTUPA Prednosti i nedostaci postojećih pristupa se analiziraju u nastavku: Tradicionalni pristupi razvoja IS U [GreeWi 2004] i [LazNeš 1998] autori daju ocene, mane i prednosti tradicionalnog pristupa, naročito Objektno orijentisane analize i dizajna. U nastavku se ocenjuje tradicionalni pristup koristeći u dobroj meri upravo ocene navedenih autora. Prednosti tradicionalnog pristupa su:  BSP, SSA, PMOV su jedne od najkorišćenijih tehnika u svetu za: Planiranje razvoja IS, Izradu funkcionalnog modela i Modela podataka.  Objektno orijentisana analiza i dizajn je osnova moderne prakse razvoja softvera  Postoje dosta tehnika i alata za modelovanje koji su opšte poznati. UML nudi dosta metoda i tehnika i predstavlja tačku okupljanja za pristupe bazirane na modelima. Postoji veliki broj knjiga u vezi UML. Ideja proširivog jezika za modelovanje sa meta modelom kao podlogom je bila njegov primarni doprinos. 212 DOMENSKO INŽENJERSTVO APLIKACIONO INŽENJERSTVO Softverska proizvodna linija (SPL) DOMENSKI INŽENJERING ZA TIP SERVISA Softverska proizvodna linija (SPL) za telekom operatora APLIKACIONO INŽENJERSTVO TOGAF The Open Group Architectural Framework Arhitektura preduzeća (EA) NGOSS The New Generation Operation System and Software TOGAF i NGOSS Biznis i IT poravnanje:  Definisanje biznisa preciznije  Podizanje nivoa biznis apstrakcija  Definisanje puta od Biznisa do IT  NGOSS - Biznis i IT poravnanje u telekomunikacijama Industrijska arhitektura Rešava problem održavanja (CIM, PIM, PSM):  Sakupljanje znanja o sistemu kroz modele  Modeli nezavisni od Implementacione Tehnologije  UML opšti jezik modelovanja  Mogu da se definišu novi pogodni jezici (DSL, profili) Sistematski Reuse:  Familije softverskih proizvoda  Automatizacija razvoja softvera  Masovna kastomizacija  SPL je mehanizam za dinamizam  Fleksibilnost - kroz Variability Efikasan razvoj u domenu telekomunikacija:  Biznis i IT poravnanje  Savlađivanje složenosti domena  Realizacija u skladu sa specifikacijom  Postepena konkretizacija  Automatizacija  Velika praznina (Gap) između modela i implementacionih tehnologija (Velika razlika u nivou apstrakcija zmeđu različitih apstraktnih nivoa (M1 – M0)).  Otežana realna automatizacija (CASE alati su neefikasni)  Nizak nivo IT apstrakcija i nema Biznis i IT poravnanja TOGAF i NGOSS  Služe uglavnom za klasifikovanje i organizovanje razvoja pa moraju da koriste druge pristupe.  Ne poseduju detalje o domenskom znanju koji su potrebni za implementaciju (TIS)  Savlađivanje složenosti domena  Problem definisanja složenih Familija  Definisanje višestrukih proizvodnih linija  Glomazni Modeli karakteristika  Potrebno domensko znanje za definisanje modela  Potrebno definisati MK i Templejte za oblast telekomunikacija Prednosti Nedostaci RAČUNARSKI NEZAVISNI MODELI Computer Independent Models - CIM PLATFORMSKI NEZAVISNI MODELI Platform Independent Models - PIM PLATFORMSKI ZAVISNI MODELI Platform Specific Models - PSM Arhitektura i razvoj vođeni modelima (MDA/MDD) OPŠTI DOMENSKI INŽENJERING TELEKOMUNIKACIONOG DOMENA FUNKCIONALNI PRISTUP OBJEKTNO ORIJENTISANI PRISTUP Tradicionalni pristup Primer: TIS – Telekomunikacioni Informacioni Sistem  Postoje tehnike i alati za razvoj  Nagomilano znanje tehnika i alata za razvoj  Postojanje realnih modela i implementacija  Manji inicijalni troškovi pri prelasku na novi pristup  Nema apstraktnih nivoa  Nizak nivo apstrakcija  Slab Reuse  Slaba efikasnost razvoja Slika 5.1. Uporedna analiza pristupa za razvoj IS - prednosti i mane. 213  Postoji veliki broj IT eksperata (analitičara, projektanata, programera, itd.) koji imaju iskustva i znanja da dobro koriste tehnike i alate tradicionalnog pristupa.  Postoji veliki broj modela i implementacija, postoji veliko i nagomilano znanje o realnim sistemima upravo u ovim modelima i implementacijama pa su manji inicijalni troškovi ako se prelazi na neki novi pristup npr. SPL. Nedostaci tradicionalnog pristupa su:  Nema odvojene apstraktne nivoe i zbog toga postoji veliki problem kod održavanja softvera.  Nizak nivo apstrakcija. UML-a jezik je imao realno mali uticaj na razvoj aplikacija. Njegova primarna korist je bila da proizvede vizuelne prezentacije klasa i veza između njih. Ograničen sa slabim mehanizmima za proširivanje, UML se brzo okovao sa konceptima programskih jezika [GreeWi 2004].  Pristup ima slabe mogućnosti za ponovno korišćenje (Slab Reuse) što utiče na slabu efikasnost razvoja softvera a time na loše Biznis i IT poravnanje [Silvius 2007].  Način dekompozicije kod objektne analize i dizajna, način dekomponovanja funkcionalnih zahteva i njihovo preslikavanje u objektno orijentisane implementacione tehnologije donosi probleme. Prvi problem je što je nekorektno da struktura rešenja treba da se poklapa sa strukturom problema. Drugi problem je da se ovim pristupima promoviše top down metodološki pristup za razvoj koji zahteva seriju adaptacija [GreeWi 2004].  UML je daleko od toga da podrži modelovanje visoko specifičnih domena (Čak i sa urađenim revizijama) [GreeWi 2004]. Telekomunikacioni Informacioni Sistem (TIS) koji je prethodno kratko prikazan je tipičan primer tradicionalnog pristupa razvoja IS, pa kao takav i dokazuje gore navedene dobre i loše strane korišćenog pristupa. Pored ostalog njega karakteriše sledeće: 214  Veliki broj funkcionalnih podsistema (poprilično pokriven telekomunikacioni domen – sadrži veliko i detaljno znanje o telekomunikacionom sistemu.  Već je desetak godina u eksploataciji u dve telekomunikacione kompanije (odrađeno je preko 200 miliona aktivnosti)  Nagomilano TIS znanje se koriste u ovoj tezi za izradu detaljnih modela jer koristeći samo TOGAF i NGOSS to ne bi moglo da se uradi. TOGAF i NGOSS služe za klasifikaciju i organizovanje razvoja i ne sadrže nivo detalja potreban za razvoj IS telekomunikacione kompanije.  TIS procesi su odvojeni od aplikacija i zato se TIS lako preslikava na NGOSS okvire  Implementiran u tehnologijama koje ne omogućavaju pravu višenivovsku arhitekturu (Oracle Forms). Teško se prevodi u Servisno Orijentisanu Arhitekturu (SOA), jer u suštini moraju da se prave nove aplikacije (Servisi)  Nema apstraktne nivoa pa je zavisan od tehnologije u kojoj je implementiran (ovo je odlika većine postojećih IS u svetu). Arhitektura i razvoj vođena modelima (MDA/MDD) Prednosti MDA/MDD pristupa su:  Omogućava rešavanje problema održavanja kroz proces razvoja vođen modelima (MDD).  Sakupljanje znanja o sistemu se radi kroz modele a ne kroz programiranje (kod). Očekivanja od MDD su da će kompajleri za specifični platformu proizvesti implementacije za mnogo platformi od jedne specifikacije što će korisnicima omogućiti očuvanje investicija kroz modele koje opisuju karakteristike aplikacija i promenu platformi ispod njih.  Arhitektura vođena modelima ima više apstraktnih nivoa. To omogućava da Modeli budu nezavisni od implementacione tehnologije [CveLaz 1988].  Započeta je automatizacija procesa razvoja primenom CASE alata koji su počeli da koriste pogodnosti viših nivoa apstrakcija [Neško01 1994]. Ovi alati su 215 pokušavali da popune praznine između viših nivoa apstrakcija i implementacionih platformi generisanjem sloja aplikacionog koda [Neško02 2006]  UML opšti jezik modelovanja, omogućava specifikaciju modela preko svojih tehnika i metoda.  Pristup omogućava definisanje novih pogodnih jezika za specifikaciju modela: Domenski specifični jezici (DSL - Domain Specific Language), definisanje profila, definisanje uzora, itd. Nedostaci MDA/MDD pristupa su:  Postoji velika praznina (Gap) između Specifikacije modela i implementacionih tehnologija (M1 – M0 nivoi).  Otežana realna automatizacija, jer CASE alati osim nekih izuzetaka nisu postigli cilj. Proizvodili su naivan i neefikasan kod i cena njegove adaptacije je bila zabrinjavajuća. Ovome treba dodati problem sinhronizacije specifikacije sa kodom u kome su nezavisno rađene promene. Ovaj problem je bio previše složen. Takođe bilo je neophodno očuvati pouzdanost alata koji proizvode implementaciju kao i pouzdanost dobavljača koji isporučuju te alate. Takođe CASE alati su nametali top down metodološki pristup, pa se javljao iterativni problem provere postojećih aplikacija (zagrljaj smrti, [ GreeWi 2004 ]).  Pristup obezbeđuje IT servise na niskom nivou apstrakcija. Posledica toga je nepostojanje Biznis i IT poravnanja, IT servisi ne mogu da podrže biznis u potrebnoj meri [Silvius 2007]. Arhitektura preduzeća (EA) Prednosti EA pristupa (TOGAF i NGOSS) su:  EA svojim sveobuhvatnim pristupom kojim se istovremeno posmatraju i biznis i IT omogućava Biznis i IT poravnanje [Silvius 2007] (Biznis i IT nisu poravnati zbog neusaglašenosti nivoa apstrakcija između Biznisa i IT-a). 216  Biznis apstrakcije nisu precizno definisane pa je teško za njih razviti IT servise. EA okviri omogućavaju preciznije definisanje biznis apstrakcija pa je onda moguće razviti kvalitetnije IT servise koje podržavaju te biznis apstrakcije.  EA omogućava podizanje nivoa IT apstrakcija. U biznisu više nije glavna potreba za IT servisima koji rešavaju nivo jednog dokumenta (ugovor, faktura, radni nalog, itd.). U biznisu je potrebno rešavati visoke biznis apstrakcije kao što su: Procesi Sa-kraja-na-Kraj, Ciljevi, Performanse kompanija, itd..  EA svojim sveobuhvatnim i istovremenim pogledom na biznis i IT definiše put od Biznisa do IT.  NGOSS je Industrijski standard za oblast telekomunikacija (Domenski EA) koji omogućava Biznis i IT poravnanje telekomunikacionog domena. Nedostaci EA pristupa (TOGAF i NGOSS) su:  Služe uglavnom za klasifikovanje i organizovanje razvoja pa moraju da koriste druge pristupe.  Ne poseduju detalje o domenskom znanju koji su potrebni za implementaciju, pa se moraju koristiti IS izgrađeni kroz tradicionalni pristup. Telekomunikacioni Informacioni Sistem (TIS) je jedan takav IS koji se u ovoj tezi koristi kao dopuna EA okvirima. Softverska proizvodna linija (SPL) Prednosti pristupa razvoja preko SPL su:  Pristup obezbeđuje sistematsko ponovno korišćenje (Large Scale Reuse) tako što je kroz domenski inženjering sve unapred predviđeno i specificirano: uzori, jezici, mehanizmi, šabloni (template), modeli, itd. Kroz aplikacioni inženjering se samo kroji softver, procesom konfigurisanja.  Rezultat domenskog inženjeringa je Familija softverskih proizvoda a ne pojedinačni SW proizvod. Familija proizvoda je suštinska inovacija u odnosu na prethodne pristupe i ona predstavlja koncept preko koga se realizuje sistematski reuse. 217  Ovaj pristup omogućava Automatizaciju procesa razvoja softvera, Automatizacijom ovaj pristup postaje veoma snažan i efikasan.  Masovna kastomizacija je problem koji se javlja posebno u oblasti servisno orijentisanog biznisa kada je potrebno masovno davati servise na korišćenje (Cloud Computing). Sistematski reuse koji je još automatizovan može da obezbedi brzu i masovnu kastomizaciju softvera.  SPL je mehanizam za dinamizam. Sistematsko ponovno korišćenje softvera koje ovaj pristup omogućava obezbeđuje efikasan i kvalitetan razvoj softvera i time u velikoj meri otklanjanje problema kašnjenja u razvoju softvera zbog dinamizma poslovnog sistema.  Kroz koncepte Zajedničko i Raznoliko pristup obezbeđuje Fleksibilnost konfigurisanja softvera, naročito se to vidi kod potreba za masovnim kastomizacijama. Nedostaci pristupa razvoja preko SPL su:  I dalje postoji problem savlađivanja složenosti domena. To se posebno vidi kod pokušaja dizajniranja SPL za jedan višedimenzionalno složeni domen kao što je to telekomunikacioni domen.  Složenost domena implicira Problem definisanja složenih Familija, pa se stalno javlja dilema da li takve SPL realizovati preko jedne složene familije proizvoda ili preko više manjih međusobno zavisnih.  Složeni Domeni za koje se definiše više međusobno zavisnih Familija proizvoda treba da se realizuju preko više međusobno zavisnih SPL. Definisanje višestrukih proizvodnih linija je novi problem koji nije baš do kraja razrešen [ReiWeb 2006].  Kada se donese odluka da se kao SPL realizuje jedna složena familija proizvoda javlja se novi problem a to su glomazni Modeli karakteristika kojima je teško upravljati [CzaHeEi 2004] [CzaHel 2005] 218 5.2.2. PREDNOSTI I NEDOSTACI NOVOG PRISTUPA ZA RAZVOJ IS TELEKOMUNIKACIONE KOMPANIJE ZASNOVANOG NA MODELIMA U ovoj tezi definiše se Pristup razvoja IS telekomunikacione kompanije zasnovan na modelima koji treba da iskoristi dobre osobine postojećih pristupa i reši probleme razvoja koje postojeći pristupi nisu rešili. U osnovi ovog pristupa je specifična softverska proizvodna linija za telekom operatora. Prednosti i nedostaci novog pristupa daju se u nastavku. Prednosti novog pristupa su:  Pristup obezbeđuje Efikasan razvoj softvera u domenu telekomunikacija kroz specifičnu arhitekturu SPL koja ima: Opšti domenski inženjering za razvoj telekomunikacionog domena, Domenski inženjering za Tip servisa, Aplikaciono inženjerstvo.  U domenu se obezbeđuje Biznis i IT poravnanje primenom NGOSS domenskog EA kojim se definišu i poravnavaju biznis i IT apstrakcije visokog nivoa kao što su procesi Sa-kraja-na-Kraj. Pored toga one se sveobuhvatno i kompletno definišu kroz klase operativnih procesa Ispunjenje (realizacija), Obezbeđenje, Fakturisanje i osiguranje prihoda (FAB – Fulfillment, Assurance, Billing and revenue assurance).  Savlađivanje složenosti domena se prvo realizuje preko dvostrukog domenskog inženjeringa a zatim tehnikom takozvanog Višenivovskog faznog konfigurisanja prema [CzaHeEi 2004] [CzaHel 2005] gde se ceo domen deli na nivoe i poddomene.  Tehnikom Višenivovskog faznog konfigurisanja se rezultati iz jednog nivoa uzimaju u obzir na narednom nivou (iz jednog poddomena u drugi) i na taj način obezbeđuje da je realizacija u skladu sa specifikacijom softvera.  Kroz Višenivovsko konfigurisanje obezbeđuje se postepena konkretizacija softvera.  Pomenuta tehnika može da se automatizuje jer je formalno definisana. 219 Nedostaci novog pristupa su:  Potrebno je veliko znanje o domenu telekomunikacija da bi se definisale sve rukotvorine SPL za telekom operatora. Okvirno znanje definiše TOGAF i NGOSS domenski EA  Da bi se definisali detaljni šabloni modela nisu dovoljni TOGAF i NGOSS. Potrebno je koristiti detaljno znanje o domenu koga najviše u postojećim IS koga treba konvertovati u šablone modela, što nije baš lak posao i nije ga lako automatizovati (reverzni inženjering). 220 6. ZAKLJUČAK U zaključku se prvo daju ostvareni rezultati u ovom radu a zatim se daje pregled tema za buduća istraživanja. 6.1. OSTVARENI REZULTATI U ovom radu su ostvareni rezultati koji su ispunili postavljene ciljeve date u uvodnom delu. Oni su dokazali i postavljenu hipotezu da je moguće izgraditi savremeni IS telekomunikacione kompanije objedinjavanjem opštih pristupa za razvoj IS i domenskog NGOSS pristupa za oblast telekomunikacija. Osnovi rezultati ostvareni u ovom radu su:  Definisan je metodološki pristup za razvoj informacionih sistema telekomunikacione kompanije zasnovan na modelima. Pristup je objedinio postojeće opšte metodološke pristupe za razvoj IS: MDA, EA, SPL, tradicionalni pristup i NGOSS pristup za razvoj IS u telekomunikacionoj industriji, tako što je iskoristio prednosti koje navedeni pristupi imaju i rešio neke nedostatke koje oni pokazuju.  Definisana je specifična arhitektura softverske proizvodne linije za telekomunikacioni domen koja čini osnovu pomenutog metodološkog pristupa. Ovakva SPL je zasnovana na NGOSS okvirima i modelima i omogućava efikasnu izgradnju IS telekomunikacione kompanije kroz tri specifična procesa: o opšti domenski inženjering telekomunikacionog domena, o domenski inženjering telekomunikacionog domena za tip servisa, o aplikacioni inženjering.  Definisani su modeli za telekomunikacioni domen u skladu sa NGOSS okvirima. Za IPTV tip servisa definisani su šabloni i instance UML modela i šabloni i instance Modela karakteristika. Za definisanje ovih modela pored 221 NGOSS okvira korišćeno je i znanje iz postojećeg informacionog sistema kompanije Telekom Srbija TIS – Telekomunikacioni Informacioni Sistem.  Definisani su mehanizmi za efikasnu transformaciju i generisanje modela koji omogućavaju generisanje IS telekomunikacione kompanije kroz postepenu konkretizaciju modela koji se nalaze na različitim nivoima apstrakcije. Prethodno nabrojani rezultati dali su značajan doprinos u rešavanju problema razvoja IS:  Savlađivanje složenosti telekomunikacionog domena definisanjem pet dimenzija složenosti: Funkcionalni domeni, Procesi Sa-kraja-na-Kraj, Tip servisa, Životni ciklus razvoja softvera, Konkretna telekom kompanija i definisanjem odnosa između dimenzija.  Poravnanje ITa i biznisa istovremenim sagledavanjem poslovanja i IS. Poslovanje je sagledano i sveobuhvatno i precizno specificirano. Definisani su procesi Sa-kraja-na-Kraj kao visoki nivoi biznis apstrakcija koje treba automatizovati (NGOSS eTOM klase procesa FAB – Fulfillment, Assurance, Billing and revenue assurance). Kroz tri nivoa specifične softverske proizvodne linije omogućen je efikasan razvoj IS što je i suština rešavanja poravnanja biznisa i IT-a.  Sistematski ponovno korišćenje softvera (Large Scale Reuse) u telekomunikacionom domenu je rešen kroz dva Reuse nivoa: Opšti domenski inženjering telekomunikacionog domena i Domenski inženjering za tip servisa, na kojima su definisane sve neophodne rukotvorine. Kroz Aplikacioni inženjering procesom konfigurisanja rukotvorina domenskog inženjeringa generiše se konkretni IS za konkretnog telekom operatora. Ovakav pristup rešava masovnu kastomizaciju softvera jer se gradi familija softverskih proizvoda iz koje se konfigurisanjem dobijaju članovi familije.  Efikasna i automatska transformacija ključnih koncepata telekomunikacionog domena: Proizvod u Servis, Servis u Resurs, Resurs u Resurse partnera. Ovi koncepti pripadaju različitim funkcionalnim oblastima telekomunikacionog domena (različitim apstraktnim nivoima gde viši nivo predstavlja specifikaciju a 222 niži realizaciju specifikacije) i njihovom automatskom transformacijom grade se klase procesa Sa-kraja-na-Kraj. Ceo metodološki pristup je detaljno ilustrovan, primerom izgradnje IS konkretnog telekom operatora IPTV servisa, u četvrtom poglavlju kroz proces aplikacionog inženjeringa. 6.2. PRAVCI BUDUĆIH ISTRAŽIVANJA Rad na definisanju pristupa za izgradnju IS telekomunikacione kompanije zasnovan na modelima otvorio je i nove teme za budući rad:  Definisanje svih tipova modela (Modeli karakteristika, UML šabloni u domenskom inženjeringu za tip servisa) za sve tipove telekomunikacionih servisa:  Širokopojasni servisi, koji dalje mogu da se klasifikuju na podtipove servisa: Internet, IPTV, VoIP, ADSL;  Servisi Fiksne telefonije, koji dalje mogu da se klasifikuju na podtipove servisa: PSTN, ISDN, Iznajmljeni vod (Leased Line) itd.  Servisi Mobilne telefonije, koji dalje mogu da se klasifikuju na podtipove servisa: Fiskalne kase, Prepaid, Postpaid, itd.  Servisi za zabavu, itd.  Profilisanje modela karakteristika za telekomunikacioni domen. Kod izrade modela karakteristika domena nedostaju odgovarajuće metodološke smernice pa ih mogu konstruisati samo vrlo iskusni projektanti sa dosta domenskog znanja o telekomunikacionom domenu. Nakon uspešne primene mehanizama profilisanja u drugim jezicima kao što su UML moguće ja takva iskustva primeniti i na modele karakteristika. Profili za modelovanje karakteristika su Uzori koji omogućavaju bolju ponovnu upotrebu znanja za modelovanje. Oni donose dodatnu semantiku koja predstavlja vodilju za manje iskusne projektante koji prave modele karakteristika.  Novi mehanizmi za instanciranje šablona modela. U ovoj tezi definisan je mehanizam za generisanje UML modela klasa koji je u suštini zasnovan na ideji 223 iz [CzaAn 2005]. Ova ideja može da se poboljša ako se iskoristi način definisanja i instanciranja šablona modela koji se daje u knjizi [Souza 1998], gde se šabloni modela predstavljaju kao UML generički modeli a njihove instance kao UML modeli. To znači da šabloni modela nisu iskazani kao unija svih instanci koje se zatim u zavisnosti od konfiguracije modela karakteristika samo uključuju ili isključuju čime se dobija konkretan model. Ovde se šablon modela predstavlja kao UML šablon čiji elementi su označeni sa uglastim zagradama (na primer < Ime servisa >) gde se konkretna instanca generiše pisanjem naziva u uglastim zagradama (na primer IPTV servis).  Definisanje fabrika softvera sa više proizvodnih linija. U prethodnom paragrafu je pokazana jedna mogućnost da se definiše fabrika softvera koja će imati više proizvodnih linija. Uobičajeno je da jedna SPL odgovara jednoj familiji softverskih proizvoda. Međutim kod složenih domena često nije moguće napraviti jednu familiju proizvoda pa onda ni jednu fabriku softvera za ceo domen. U ovoj tezi ceo telekomunikacioni domen je posmatran kao jedna familija proizvoda. Za tu familiju napravljena je specifična SPL koja ima dva dela domenskog inženjeringa: opšti domenski inženjering telekomunikacionog domena i domenski inženjering za tip servisa. Postojanje ova dva dela domenskog inženjirnga ukazuju na to da je i ovo fabrika koja se sastoji iz dve SPL. Sve ovo ukazuje da za ovakve domene mogu i drugačije da se definišu familije proizvoda, da ih ima više i da se za svaku famuliju pravi posebna SPL. SPL bi bile međusobno zavisne onako kako su zavisne međusobno i familije proizvoda.  Definisanje SPL za ceo životni ciklus po TOGAF okviru koji ne obuhvata samo faze razvoja softvera već i njegovu implementaciju u konkretnoj kompaniji, njegovo održavanje i izmene dok on funkcioniše. Pored toga treba imati u vidu da u svakoj kompaniji postoji već neki softver koji funkcioniše, da treba obezbediti migraciju u novi softver dobijen pomoću SPL.  Automatizacija celog metodološkog pristupa bi učinila pristup veoma snažnim. Automatizacija obuhvata: automatizaciju osnovnih mehanizama za 224 transformaciju i generisanje modela, Automatizaciju čitavih šema za višenivovsko fazno konfigurisanje, Automatizaciju kompletnih procesa koji vode postupak generisanja kompletnog IS, itd.  Metodološki pristup za razvoj IS telekomunikacione kompanije ima potencijal da preraste u opšti pristup za razvoj IS. Opšti domenski inženjering telekomunikacionog domena je vrlo blizu da bude opšti domenski inženjering za bilo koji domen. Domenski inženjering za tip servisa je promenljivi deo SPL, modeli zavise od tipa domena (tako i u ovom radu zavise od tipa servisa).. I na kraju kao što se iz prethodnog vidi pored toga što je ovim radom je ostvareno dosta rezultata i doprineto rešavanju puno aktuelnih problema razvoja IS, istovremeno je otvoreno je dosta novih tema za budući rad jer je ova oblast istraživanja veoma složena. 225 7. LITERATURA [ AniNVC 2012 ] N. Aničić, S. Nešković, M. Vučković, R. Cvetković, “Specification of Data Scheme Mappings using Weaving Models”, ComSIS 386-1108, 2012, (DOI) 10.2298/CSIS110823010A [ AtGuKe 2009 ] C. Atkinson, M. Gutheil, B. Kennel, “A Flexible Infrastructure for Multilevel Language Engineering”, IEEE Transactions on Software Engineering, vol. 35, No. 6., 2009. [ AtkKuh 2001 ] C. Atkinson and T. Kuhne, “The Essence of Multilevel Matamodeling”, Proc. Fourth Int`l Conf. Unified modeling Languages, Concept and Tools, 2001. [ AtkKuh 2003 ] C. Atkinson and T. Kuhne, “Model-Driven Development: a metamodeling fondation”, Software, IEEE Volume 20, Issue 5, Sept- Okt 2003 Page(s): 36-41. [ AtkKeGo 2010 ] C. Atkinson, B. Kennel, B. Goß, “The Level-Agnostic Modeling Language”, SLE 2010: 266-275. [ BiScKr 2005 ] Bittler, R. Scott, and Gregg Kreizman. "Gartner Enterprise Architecture Process: Evolution 2005." October 21, 2005. Gartner ID: G00130849 [ Booch 1994 ] G. Booch, “Object Oriented Analysis and Design With Applications. Second Edition”. Addison-Wesley, 1994. [ BoRuJa 1999 ] G. Booch, J. Rumbaugh, I. Jacobson, “The Unified Modeling Language User Guide”. Addison-Wesley, 1999. [ BSPM 1981 ] "Business System Planning Methodology ", IBM GE20-0577-2, IBM Corporation, New York, 1981. 226 [ Chen 1976 ] P. Chen, “The entity-relationship model – toward a unified view of data”, ACM Transactions and Database Systems (TODS), Volume 1, Issue 1, March 1976. [ CIOC 1999 ] The Chief Information Officers Council A04, “Federal Enterprise Architecture Framework”, Version 1.1. September 1999. [ CliCo 1996 ] Clinger-Cohen Act of 1996 (PL 107-347) (See THOMAS (Library of Congress).) [ CveDan 1997 ] R. Cvetković, M. Danilović, i drugi, "Meta baza podataka kao osnovna komponenta sistema za generisanje izveštaja", INFOTEH, Vrnjačka Banja, 1997.godine. [ CveLaz 1988 ] R. Cvetković, B. Lazarević, "Jedan pristup modeliranju podataka uz pomoć računara", SARAJEVO - JAHORINA, 1988. godine. [ CveMA1 1995 ] R. Cvetković, Z. Mirosavljević, M. Antić, "Informacioni sistem za evidentiranje i održavanje telekomunikacionih kapaciteta", YU INFO 95, Brezovica, 1995. godine. [ CveJN 1995 ] R. Cvetković, R. Jovanović, J. Novković, "Informacioni sistem za održavanje telekomunikacionih sistema", ODRŽAVANJE I EKSPLOATACIJA TELEKOMUNIKACIONIH KAPACITETA, Zlatibor, 1995. Godine [ Cve01 1995 ] R. Cvetković, "Osnovni elementi i karakteristike baze podataka IS-a za održavanje i eksploataciju telekomunikacionih kapaciteta", ODRŽAVANJE I EKSPLOATACIJA TELEKOMUNIKACIONIH KAPACITETA – I savetovanje, Zlatibor, 1995. Godine [ Cve02 1995 ] R. Cvetković, "Neka iskustva u razvoju i uvođenju IS-a za održavanje i eksploataciju telekomunikacionih kapaciteta", ODRŽAVANJE I EKSPLOATACIJA TELEKOMUNIKACIONIH KAPACITETA – I savetovanje, Zlatibor, 1995. Godine [ Cve03 1995 ] R. Cvetković, "Metodološki analiza i ocena postojećeg informacionog sistema u složenim poslovnim sistemima", YU INFO 95, Brezovica, 1995. godine. [ CveĐo 1996 ] R. Cvetković, M. Đorović, "Kriterijumi za definiciju sadržaja i redosleda programskih sistema", YU INFO 96, Brezovica, 1996. godine. 227 [ CveLo 1995 ] R. Cvetković, D. Lopičić, "Informacioni podsistem za uvođenje i evidentiranje telekomunikacionih kapaciteta", ODRŽAVANJE I EKSPLOATACIJA TELEKOMUNIKACIONIH KAPACITETA – I savetovanje, Zlatibor, 1995. Godine [ CveMA2 1995 ] R. Cvetković, Z. Mirosavljević, M. Antić, "Informacioni podsistem za prijem i rešavanje zahteva", ODRŽAVANJE I EKSPLOATACIJA TELEKOMUNIKACIONIH KAPACITETA – I savetovanje, Zlatibor, 1995. Godine [ CveJMK1 1996 ] R. Cvetković, R. Jovanović, A. Miletić, G. Kosanović, "Otklanjanje smetnji na telekomunikacionim kapacitetima uz pomoć TIS-a", INFOTEH, Vrnjačka banja, 1996. Godine [ CveJOĐ 1999 ] R. Cvetković, R. Jovanović, V. Odalović, J. Đorović, i drugi, "MTPRO – IT rešenje za podršku prodaji usluga i proizvoda mobilne telefonije", TELFOR 99, Beograd, 1999. godine. [CveJMK2 2001 ] R. Cvetković, R. Jovanović, A. Miletić, G. Kosanović, "Sistem za upravljanje poslovima", YU INFO 2001, Kopaonik, 2001. godine. [CveJMK3 2001 ] R. Cvetković, R. Jovanović, A. Miletić, G. Kosanović, "Sistem za upravljanje poslovima kao jezgro informacionog sistema", YU INFO 2001, Kopaonik, 2001. godine. [CveJMK4 2004 ] R. Cvetković, R. Jovanović, B. Perić, A. Miletić, G. Kosanović, "TIS - Telekomunikacioni informacioni sistem", INFOTEH, Vrnjačka Banja, 2004.godine. [Cve03 2005 ] R. Cvetković, "Ka novoj generaciji TIS-a", TELFOR 2005, Beograd, 2005. godine. [ CveDa1 2005 ] R. Cvetković, B. Damjanović, "Extending TIS with Autodesk GIS technology", Autodesk in Telecommunication, Rumunija, Bukurešt, 2005. godine. [ CveDa2 2005 ] R. Cvetković, B. Damjanović, "Extending TIS with Autodesk GIS technology and Oracle eAM", Autodesk University, Orlando, USA, 2005. godine. [ CveNe 2010 ] R. Cvetković, S. Nešković, "Jedna vizija OSS/BSS telekoma", YU INFO 2010, Kopaonik, 2010. godine. [ CveNe01 2010 ] R. Cvetković, S. Nešković, „An Approach to Defining Scope in Software Product Lines for the Telecommunication Domain”, Advances in Databases and Information Systems - 14th East European Conference 2010, Lecture Notes in Computer Science, 6295 pp 555- 558, Springer Verlag Berlin Heidelberg 2010, DOI: 10.1007/978-3- 228 642-15576-5_44 2010. [ CzaEi 2000 ] K. Czarnecki and U. Eisenecker, “Generative Programming: Methods, Tools, and Applications”, Addison-Wesley, 2000. [ CzaBUE 2002 ] K. Czarnecki, T. Bednasch, P. Unger, U. Eisenecker, “Generative Programming for Embedded Software: An Industrial Experience Report”, Springer-Verlang LNCS 2487, pp 156-172, 2002. [ CzaHeEi 2004 ] K. Czarnecki, S. Helsen, U.Eisenecker, “Staged Configuration Using Feature Models”, R.L. Nord (Ed.): SPLC 2004, LNCS 3154, pp. 266- 283, 2004. [ CzaHel 2005 ] K. Czarnecki, S. Helsen, “Staged Configuration trough Specialization and Multilevel Configuration of Feature Models”, Soft. Process Improve. Pract. 10 143 – 169., 2005. [ CzaHeEi 2005 ] K. Czarnecki, S. Helsen, U. Eisnecker, “Formalizing Cardinality-based Feature Models and their Specialization”, Soft. Process Improve. Pract. 10 7 – 29, 2005. [ CzaAn 2005 ] K. Czarnecki, M. Antkiewicz, “Mapping Features to Models: A Template Approach Based on Superimposed Variants”, LNCS 3676, pp. 422-437, Springer-Verlag Berlin Heidelberg. 2005. [ DeMarco 1978 ] T. DeMarco, “Strusctured Analisys and System Specification”, Yordon Inc 1978. [ Dijkstra 1976 ] E.W. Dijkstra, “A Discipline of Programming”, Prentice-Hall 1976. [ ĐorCPŽV 1995] M. Đorović, R. Cvetković, B. Perić, D. Živković, A. Vaš, "Metodološki pristup planiranju razvoja informacionih sistema u velikim poslovnim sistemima", YU INFO 95, Brezovica, 1995. godine. [ eTOM01 2010 ] GB921, “Business Process Framework (eTOM) - Concept and Principles”, Release 8.1, Version 8.5, TeleManagemnt Forum 2010. 229 [ eTOM02 2009 ] GB921P, “Business Process Framework (eTOM) – Addendum P: An eTOM Primer”, Release 8.0, Version 4.7, TeleManagemnt Forum 2009. [ eTOM03 2009 ] GB921B, “Business Process Framework (eTOM) – Addendum B: B2B Integration Work”, Release 7.0, Version 7.2, TeleManagemnt Forum 2009. [ eTOM04 2010 ] GB921D, “Business Process Framework (eTOM) – Addendum D: Process Decompositions and Descriptions”, Release 9.0, Version 9.2, TeleManagemnt Forum 2010. [ eTOM05 2009 ] GB921F, “Business Process Framework (eTOM) – Addendum F: Guide to Applying Business Process Framework”, Release 8.0, Version 7.7, TeleManagemnt Forum 2009. [ eTOM06 2010 ] GB921G, “Business Process Framework (eTOM) – Addendum G: Process Flow Examples”, Release 8.1, Version 0.1, TeleManagemnt Forum 2010. [ FEA01 2006 ] “Federal Enterprise Architecture Program EA Assessment Framework 2.1”, December 2006. [ GreeWi 2004 ] J. Greenfield, J. Wiley, “Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools”, ISBN:0471202843, 2004. [ IEW 1988 ] “Information Release Workbench, Release 5.0”, KnowledgeWare Inc, Atlanta, USA, 1988. [ JacCJO 1992 ] I.Jacobson, M.Christerson, P.Jonsson, G.Övergaard, “Object-Oriented Software Engineering: a Use Case Driven Approach”, Addison- Wesley, 1992. [ JGRHLG 2005 ] James, Greta A., Robert A. Handler, Anne Lapkin, and Nicholas Gall. "Gartner Enterprise Architecture Framework: Evolution 2005." October 25, 2005. Gartner ID: G00130855 [ JovCve 1995 ] R. Jovanović, R. Cvetković, "Jedan način za generisanje izveštaja u CICS okruženju", YU INFO 95, Brezovica, 1995. godine. [ Kakola 2010 ] T.Kakola, “Standards Initiatives for Software product Line Engineering and Management within the International Organization for Standardization”, IEEE Computer Society, 978-0-7695-3869-3&10, 2010. 230 [ Kang 2010 ] K.Kang, “FODA: Twenty Years of Perspective on Feature Modeling”, VaMoS POSTECH, 2010. [ KCHNP 1990 ] K.Kang, S.Cohen, J.Hess, W.Nowak, S.Peterson, “Feature-oriented domain analysis (FODA) feasibility study”, Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1990. [ LazNeš 1997 ] B. Lazarević, S. Nešković, “Objektno-orijentisani pristup razvoju informacionih sistema”, FON, Beograd. 1997. [ LazNeš 1998 ] B. Lazarević, S. Nešković, “Sistemsko-Teorijska kritika objektno orijentisanih pristupa razvoju IS”, FON, Beograd. 1998. [ LazMAB 2003 ] B. Lazarević, Z. Marjanović, N. Aničić, S. Babarogić, “Baze podataka”, FON, Beograd. 2003. [ MellBal 2002 ] S.J. Mellor, M.J. Balcer, “Executable UML: A Fondation for Model- Driven Architecture”, Addison Wesley, ISBN 0-201-74804-5, 2002. [ MillMuk 2001 ] J. Miller, J. Mukerji, “Model Driven Architecture (MDA)”, OMG Document 2001, http://www.omg.org. [ MillMuk 2003 ] J. Miller, J. Mukerji, .. “MDA Guide Version 1.0”, OMG Document 2003, http://www.omg.org. [ NešAV 2007 ] S. Nešković, N. Aničić, M. Vučković, i drugi, “TIS/NGOSS Repozitorij zasnovan na MDA modelima – Idejni projekat”, FON – Laboratorija za informacione sisteme, Beograd, 2007. [ NešCve 2011 ] S. Nešković, R. Cvetković, “Extending Feature Models with Deep Instantiation to Manage Complexity and Dynamism of Services”, First International Workshop on Service Oriented-Architecture and ITSM, August 29-September 02, Toulouse, France 2011. Proceedings of DEXA Workshops, IEEE Computer Society, ISBN: 978-0-7695- 4486-1 DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/DEXA.2011.33. [ Neško01 1994 ] S. Nešković, i drugi, “ CASE alat ARTIST”, FON, Beograd, 1994. 231 [ Neško02 2006 ] S. Nešković, Doctoral Dissertation: A Methodology and CASE tool for IS Development Based on Stepwise Concretization of Abstract Specifications, Belgrade University, 2006. [ NGOSS01 2004 ] GB927, “The NGOSS Lifecycle and Methodology”, Release 4.5, TeleManagemnt Forum 2004. [ NGOSS02 2009 ] GB942, “NGOSS Contracts Concept and Principles”, Release 1.0, Version 1.3, TeleManagemnt Forum 2009. [NovJC 1996 ] J. Novković, R. Jovanović, R. Cvetković, i drugi, "Privremeno isključenje pretplatnika uz pomoć telekomunikacionog informacionog sistema", YU INFO 96, Brezovica, 1996. godine. [OMG 2002 ] "Meta Object Facility (MOF) Specification v 1.4.", OMG Document formal /02-04-03, 2002. [ OMG 2012 ] www.omg.org [ Parnas 1972 ] D. Parnas, “On the Criteria to be Used in Decomposing a System into Modules”, Communications of the ACM. ACM Press, December 1972. [ Parnas 1976 ] D. Parnas, “On the Design and Development of Program Families”, IEEE Transactions on Software Engineering, March 1976. [ Pavel 2006 ] H.Pavel, “Model-Driven Design Using Business Patterns”, Springer, 2006. [ PešCve 2001 ] D. Pešić, R. Cvetković, "Standardi razvoja klasa u Oracle/Developer okruženju", INFOTEH, Vrnjačka Banja, 2001.godine. [ PoBoLi 2005 ] K.Pohl, G.Böckle, F.van der Linden, “Software Product Line Engineering Foundations, Principles, and Techniques”, Springer, 2005. [ Rambua 1991 ] J. Rambuaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson, “Object Oriented Modeling and Design”, Prentice Hall, 1991. [ ReCre 2005 ] J.P. Reilly, M.J. Creaner, “NGOSS distilled: The Essential Guide to Next Generation Telecoms Management”, TM forum, UK 2005.. 232 [ Reilly 2007 ] J.P. Reilly, “Getting Started with the SID: A SID Modeler’s Guide”, TM forum, 2007. [ ReiWeb 2006 ] M. O. Reiser, M. Weber, “Managing Highly Complex Product Families with Multi-Level Feature Trees” 14th IEEE International Requirements Engineering Conference (RE'06) 0-7695-2555-5/06 $20.00 © 2006 IEEE. [ Sessions 2007 ] Roger Sessions, “A Comparison of the Top Four Enterprise- Architecture Methodologies”, ObjectWatch, Inc. May 2007. [ SID01 2010 ] GB922, “Information Framework (SID) - Concept and Principles”, Release 9.0, Version 7.14, TeleManagemnt Forum 2010. [ SID02 2009 ] GB922 - Addendum 1A, “Shared Information / Data (SID) Model - Common Business Entity Definitions – Agreement (Including Service Level Agreement”, Release 6.0, Version 6.4., TeleManagemnt Forum 2009. [ SID03 2010 ] GB922 - Addendum 1U “Information Framework (SID) – User’s Guide”, Release 8.1, Version 8.2, TeleManagemnt Forum 2010. [ SID04 2009 ] GB922 - Addendum 1 Performance “Information Framework (SID) – Performance Business Entities”, Release 8.0, Version 1.3, TeleManagemnt Forum 2009. [ SID05 2010 ] GB922 - Addendum 1 Usage “Information Framework (SID) – Usage Business Entity Definitions”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID06 2004 ] GB922 - Addendum 1J, “Shared Information / Data (SID) Model - PROJECT Business Entity Definitions”, Release 4.0, Version 1.2, TeleManagemnt Forum 2004. [ SID07 2004 ] GB922 - Addendum 1L, “Shared Information / Data (SID) Model – Common Business Entity Definitions - Location”, Release 4.0, Version 3.2, TeleManagemnt Forum 2004. [ SID08 2010 ] GB922 - Addendum 1P, “Shared Information / Data (SID) Model – Common Business Entity Definitions - Party”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID09 2004 ] GB922 - Addendum 1POL, “Shared Information / Data (SID) Model – Common Business Entity Definitions - Policy”, Release 4.0, Version 1.1, TeleManagemnt Forum 2004. 233 [ SID10 2010 ] GB922 - Addendum 1R, “Shared Information / Data (SID) Model – Common Business Entity Definitions – Root Business Entities”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID11 2004 ] GB922 - Addendum 1T, “Shared Information / Data (SID) Model – Time Related Business Entity Definitions”, Release 4.0, Version 1.2, TeleManagemnt Forum 2004. [ SID12 2010 ] GB922 - Addendum 2, “Shared Information / Data (SID) Model – Customer Business Entity Definitions”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID13 2010 ] GB922 - Addendum 3, “Shared Information / Data (SID) Model – Product Business Entity Definitions”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID14 2004 ] GB922 - Addendum 4S-QoS, “Shared Information / Data (SID) Model – Quality of Service Business Entity Definitions”, Release 4.0, Version 1.1, TeleManagemnt Forum 2004. [ SID15 2010 ] GB922 - Addendum 4SO, “Information Framework (SID) – Service Overview Business Entity Definitions”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID16 2010 ] GB922 - Addendum 5LR, “Information Framework (SID) – Logical Resource and Compound Resource Business Entity Definitions”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID17 2010 ] GB922 - Addendum 5PR, “Information Framework (SID) – Physical Resource Business Entity Definitions”, Release 9.0, Version 9.3, TeleManagemnt Forum 2010. [ SID18 2009 ] GB922 - Addendum 6, “Information Framework (SID) – Market/Sales Business Entity Definitions”, Release 8.0, Version 2.2, TeleManagemnt Forum 2009. [ SID19 2009 ] GB922 - Addendum 7RA, “Information Framework (SID) – Enterprise Domain Revenue Assurance Business Entities”, Release 7.0, Version 1.2, TeleManagemnt Forum 2009. [ Silvius 2007 ] A.J. Gilbert Silvius, “Business & IT Alignment in theory and practice”, Proceedings of 40 th Annual Hawaii International Conference on System Sciences (HICSS207), IEEE. 2007. [ Souza 1998 ] D. D'Souza and A. Wills. “Objects, Components And Frameworks With UML”. Addison-Wesley, 1998. [ Stojim 2011 ] D. Stojimirov “Realizacija transformacije modela primenom smarty mehanizma za šablone”, završni rad - FON, 2011. 234 [ TAFIM 1994 ] U.S. Department of Defense, “Technical Architecture Framework for Information Management (TAFIM)”, Volumes 1-8. Version 2.0. Reston, VA: DISA Center for Architecture, 1994. [ TAM01 2010 ] GB929, “Application Framework (TAM) Map – The BSS/OSS Systems Landscape”, Release 4.0, Version 4.2, TeleManagemnt Forum 2010. [ TMF01 2011 ] http://www.tmforum.org/browse.aspx [ TMF02 2005 ] TMF053, “The NGOSS Technology Neutral Architecture”, Release 6.0, TeleManagemnt Forum 2005. [ TMF03 2004 ] TMF053D, “NGOSS Architecture Technology Neutral Specification Metamodel”, Release 4.0, TeleManagemnt Forum 2004. [ TNA01 2010 ] GB942CP, “Integration Framework – Business Services (Contracts) Concepts and Principles”, Release 7.0, Version 1.2, TeleManagemnt Forum 2010. [ TNA02 2010 ] GB942MAP, “TM Forum Frameworx Mapping – Business Process, Information, Application, and Integration Frameworx”, Release 2.1, Version 0.8, TeleManagemnt Forum 2010. [ TNA03 2010 ] GB942U, “Integration Framework – Business Services (Contracts) User Guidelines”, Release 2.1, Version 2.07, TeleManagemnt Forum 2010. [ TOGAF01 2011 ] www.opengroup.org/togaf [ TOGAF02 2009 ] The Open Group, “The Open Group Architectural Framework (TOGAF)”, version 9. 2009. [ UML 2003 ] “Unified Modeling Language Specification v 1.5”, OMG Document formal /03-03-01 2003. [ Wieringa 1998 ] R. Wieringa, “A Survey of Structured and Object-Oriented Software Specification Method and Techniques”, ACM Comput. Surv. 30(4): 459-527, 1998. [ Zachman 1987 ] J. A. Zachman, “A Framework for Information Systems Architecture”, IBM Systems Journal, vol. 26, no. 3, IBM Publication G321-5298. 914-945-3836 or 914-945-2018. 1987. 235 [ ZimmKG 2004 ] O. Zimmermann, P. Krogdahl, C. Gee, “Elements of Service-Oriented Analysis and Design“, IBM, Software Group, 2004, http://www.ibm.com/developerworks/webservices/library/ws-soad1/. BIOGRAFIJA AUTORA Radovan Cvetković, je rođen 18.9.1955. godine u mestu Trebinja, opština Kuršumlija, Republika Srbija. Osnovnu, a zatim i srednju PTT školu (odsek vezan za telekomunikacije) završio je u Beogradu. 1983. godine je diplomirao na FON-u, organizaciono-kibernetski smer, kod profesora Branislava Lazarevića, sa ocenom 10 (prosečna ocena tokom studija 8,1). 1989. godine je magistrirao na Fakultetu organizacionih nauka, smer informacioni sistemi, kod istog profesora i sa temom „Jedan način modeliranja podataka uz pomoć računara“. Radnu karijeru je započeo u PTT organizaciji Beograd – Gradski telefon, gde je desetak godina radio na poslovima održavanja pristupne kablovske telekomunikacione mreže. Posle toga prelazi u računski centar PTT organizacije Beograd. Ubrzo zatim postaje rukovodilac razvoja softvera i uvodi metodološki pristup u razvoju softvera i sa saradnicima razvija i implementira veliki broj softverskih podsistema. Od osnivanja kompanije Telekom Srbija 1997. do 2005. godine radio je na poslovima Direktora sektora za razvoj softvera u Direkciji za informacione tehnologije. Od 2005. do 2009, godine bio je direktor Direkcije za informacione tehnologije. U ovom trenutku nalazi se na poziciji eksperta za razvoj i implementaciju IS Telekoma u Direkciji za tehniku. U svojoj radnoj karijeri rukovodio je razvojem i uvođenjem u eksploataciju velikog broja softverskih podsistema u raznim kompanijama. Od svih njih sigurno je najznačajniji TIS (Telekomunikacioni Informacioni Sistem), veoma složen sistem, koji funkcioniše u kompanijama Telekom Srbija i Telekom Srpske - Banja Luka. Za ovaj softver su dobijena mnoga svetska i domaća priznanja. Radovan Cvetković je radio samostalno ili sa drugima studije dugoročnog razvoja IS za: Vladu Crne Gore, Energoprojekt, JP PTT saobraćaja Srbija, Prvi partizan, Lolu korporaciju, Fabriku mašinskih odlivaka, Dunav osiguranje, Novi Sad – Gas, Hidroelektranu Đerdap, SAMSON kompaniju, itd. Najvažnija znanja i oblasti interesovanja su vezana za metode i tehnike razvoja i implementacije složenih informacionih sistema. 1. Autorstvo - Dozvoljavate umnožavanje, distribuciju i javno saopštavanje dela, i prerade, ako se navede ime autora na način određen od strane autora ili davaoca licence, čak i u komercijalne svrhe. Ovo je najslobodnija od svih licenci. 2. Autorstvo – nekomercijalno. Dozvoljavate umnožavanje, distribuciju i javno saopštavanje dela, i prerade, ako se navede ime autora na način određen od strane autora ili davaoca licence. Ova licenca ne dozvoljava komercijalnu upotrebu dela. 3. Autorstvo - nekomercijalno – bez prerade. Dozvoljavate umnožavanje, distribuciju i javno saopštavanje dela, bez promena, preoblikovanja ili upotrebe dela u svom delu, ako se navede ime autora na način određen od strane autora ili davaoca licence. Ova licenca ne dozvoljava komercijalnu upotrebu dela. U odnosu na sve ostale licence, ovom licencom se ograničava najveći obim prava korišćenja dela. 4. Autorstvo - nekomercijalno – deliti pod istim uslovima. Dozvoljavate umnožavanje, distribuciju i javno saopštavanje dela, i prerade, ako se navede ime autora na način određen od strane autora ili davaoca licence i ako se prerada distribuira pod istom ili sličnom licencom. Ova licenca ne dozvoljava komercijalnu upotrebu dela i prerada. 5. Autorstvo – bez prerade. Dozvoljavate umnožavanje, distribuciju i javno saopštavanje dela, bez promena, preoblikovanja ili upotrebe dela u svom delu, ako se navede ime autora na način određen od strane autora ili davaoca licence. Ova licenca dozvoljava komercijalnu upotrebu dela. 6. Autorstvo - deliti pod istim uslovima. Dozvoljavate umnožavanje, distribuciju i javno saopštavanje dela, i prerade, ako se navede ime autora na način određen od strane autora ili davaoca licence i ako se prerada distribuira pod istom ili sličnom licencom. Ova licenca dozvoljava komercijalnu upotrebu dela i prerada. Slična je softverskim licencama, odnosno licencama otvorenog koda.