ONTOLOJĠ TABANLI ĠZLENMESĠ ve YÖNETĠMĠ LİSANS TEZİ HAZIRLAYANLAR Umut BENZER Özlem GÜRSES DANIŞMAN Yrd. Doç. Dr. Murat Osman ÜNALIR Haziran, 2011 İZMİR
Umut GÜRSES, Özlem Lisans Tezi, Bilgisayar Mühendisliği Bölümü Tez DanıĢmanı: Yrd. Doç. Dr. Murat Osman ÜNALIR Haziran 2011, 126 sayfa Bu tez kapsamında Ģirketlerin sahip olduğu yazılım varlıklarının ontoloji tabanlı olarak tutulabilmesi için bir ontoloji modeli geliĢtirilmiĢtir. Yazılım varlıklarının ontolojilerde tutulması, bağımlılık (dependency), uyum (compatibility) ve buna benzer iliĢkilerin çıkarsanabilmesini sağlamaktadır. Bu ontolojiyi kullanan yazılımlar ile yazılım varlıklarının birbirleri ile ilgili uyumsuzluk veya sağlıklı çalıĢmamalarından kaynaklanan problemler ve bunların diğer hangi varlıkları etkilediği tespit edilebilecektir. Tez kapsamında yazılım varlıklarının yönetimi ile ilgili uluslararası standartlar (ISO/IEC 19770 1-2), Bilgi Teknolojileri (BT) yönetimi hakkında standartlar (Information Technology Infrastructure Library) incelenmiĢtir. Yazılım varlıklarının bilgilerinin tutarlı olarak ve süreklilik arz edecek Ģekilde sisteme eklenmesini sağlayacak metodolojiler konusunda bilgi sahibi olunmuĢtur. Tez kapsamında bilgi edinme süreci ve metodolojilere değinilecektir. Anahtar sözcükler: ISO/IEC 19770, Information Technology Infrastructure Library (ITIL), Software Asset Management (SAM), OWL, Protégé, Jena
ASSETS BENZER, Umut GÜRSES, Özlem BSc in Computer Eng. Supervisor: Assistant Professor Dr. Murat Osman ÜNALIR June 2011, 126 pages In this thesis an ontology model has been developed to manage software assets of a company. Storing software assets in ontology enables dependency and compatibility relationships to be inferred. Programs that use this ontology as a data model can easily find out incompatibility and similar problems and effects of these problems in other programs. Scope of this thesis includes international standards about IT management and Software Asset Management. ISO/IEC 19770 1-2 and Information Technology Infrastructure Library v2 and v3 (ITIL) are studied. This provided a methodology for accessing and updating ontology instances. This is important due to providing consistent and complete of ontology. Keywords: ISO/IEC 19770, Information Technology Infrastructure Library (ITIL), Software Asset Management (SAM), OWL, Protégé, Jena
Sayın Yrd. Doç. Dr. Murat Osman Ünalır baĢta olmak üzere, tez çalıĢması süresince birlikte çalıĢma imkânı bulduğumuz TÜPRAġ Ġzmir Rafinerisi ve Genel Müdürlüğü‟nden Sayın KurtuluĢ Pesen, Sayın Mustafa Bakır, Sayın Çağlar Durmaz, Sayın Mehmet Aydın‟a ve projede beraber çalıĢtığımız sayın Dr. Dilek Tapucu‟ya teĢekkürü bir borç biliriz.
Ek 1: Bir BakıĢta ITIL v3 Süreçleri ....................................................... 103 Ek 2: ITIL v3 Süreçlerinin AkıĢı............................................................ 104 Ek 3: ISO 19770-1 Kapsamında Yazılımla Ġlgili Olmayan Hangi Varlıkların Yönetilebileceğine Dair Tablo ...................................................... 105 Ek 4: ISO 19770-1 Süreçlerinin Tablo Halinde Gösterimi .................... 106 Ek 5: Tez Kapsamında Ġncelenen SAM Yazılımları .............................. 107 Microsoft Desktop Optimization Pack ............................................... 107 AuditPro ............................................................................................. 107 AssetExplorer ..................................................................................... 107 Asset Tracker...................................................................................... 107 Express Software Manager................................................................. 108 CDW Software Asset Management ................................................... 108 IBM - Rational Asset Manager .......................................................... 108 Ek 6: Software Identification Tag YaĢam Döngüsü............................... 109 Ek 7: „regid‟ Değerlerinin Örnekleri ...................................................... 110 Ek 8: Farklı Platformlar Ġçin Tag Konumu Örnekleri ............................ 111 Ek 9: Software Identification Tag Yönetimi Ġçin Windows Vista API‟leri ......................................................................................................................... 112
yönetilemeyen yazılımlara örnekler ................................................................................................................ 105 Tablo 2: ISO 19970-1 süreçlerinin tablo halinde gösterimi ....................... 106 Tablo 3: Farklı platformlar için .swidtag konumu örnekleri ...................... 111 Tablo 4: .swidtag yönetimi için Windows Vista tarafından sunulan API'ler ............................................................................................................................. 112
CMDB Configuration Management Database CPU Central Processing Unit CSI Continual Service Improvement DBMS Database Management System FOAF Friend of a Fried GUID Globally Unique Identifier ICT Information and Communications Technology IEC International Electrotechnical Commission IETF Internet Engineering Task Force ISO International Standards Organization IT Information Technology ITIL Information Technology Infrastructure Library LUN Logical Unit Number MD5 Message-Digest Algorithm 5 RBT Rafineri Bilgi Teknolojileri PDA Personal Digital Assistant
Small Computer System Interface SKOS Simple Knowledge Organization System SKU Stock Keeping Unit SLA Service Level Agreement SMTP Simple Mail Transport Protocol SPARQL SPARQL Protocol and RDF Query Language Swidtag Software Identification Tag OGC Office of Government Commerce OLA Operational Level Agreement OWL The Web Ontology Language TÜPRAġ Türkiye Petrol Rafinerileri Anonim ġirketi UNSPSC United Nations Standard Products and Services Code URI Uniform Resource Identifier XML Extensible Markup Language XSD XML Schema Definition
iĢletim sistemi, ağ aygıtı, veritabanı, süreç yönetim sistemleri, kiĢiler ve dokümanlardan oluĢmaktadır. (TÜPRAġ BSM, 2010, s. 2) RBT varlıklarının sayısı her geçen gün artmaktadır. Bu varlıkların birbirleriyle olan iliĢkilerinden dolayı, varlık karmaĢıklığı ise logaritmik olarak yükselmektedir. TÜPRAġ‟ın Rafineri Bilgi Teknoloji Varlıklarının Ontoloji Tabanlı Ġzlenmesi ve Yönetimi isimli TÜBĠTAK projesinin temel hedefi bu varlıkların ve gelecekte eklenebilecek varlıkların tamamının yönetilebilmesini sağlamaktır. Tezimiz, RBT varlıklarının “yazılım varlıkları” kısmı ile ilgili olup, bu proje ile ortak yürütülmektedir. Yazılım Varlıklarının Ontoloji Tabanlı Ġzlenmesi ve Yönetimi‟ndeki temel amaç, bir sistemdeki yazılımlar ve bunlarla ilgili olan varlıkların yönetilebileceği, varlıkların kendileriyle alakalı ve birbirleriyle olan iliĢkilerinden doğan özelliklerini (uyumluluk, bağımlılık vs.) tutabilecek, çıkarsamalar ile sıkıntı yaratabilecek yazılım gruplarını tespit edebilecek bir ontoloji modeli oluĢturmaktır. Ancak bu modelin yaratılması tek baĢına yeterli olmamaktadır: Yönetilecek yazılım varlıklarının belirlenmesi, ontolojideki bilgilerin sürekli güncel tutulması, bunlar ile ilgili standartlar ve ontoloji ile geliĢtirilebilecek programlar da araĢtırılmalıdır. Aksi halde geliĢtirilmiĢ ayrıntılı bir ontoloji, içindeki bilgiler güncel tutulamadığı ve sağlıklı yararlanılamadığı için iĢe yaramayacaktır. Bu sebeple tezimiz kapsamında yazılım varlıkları ile ilgili metodoloji ve standartların incelenmesine önem verilmiĢtir. Tez kapsamında bir yıl boyunca yaptığımız çalıĢmaları kronolojik olarak Ģu Ģekildedir: Öncelikle TÜPRAġ‟ın projesi ve ne yapmayı amaçladığı anlaĢılmıĢ ve böylece projeye dahil olunmuĢtur. Sonra, yazılım varlıkları (software asset) ile ilgili uluslararası standartlar araĢtırılmıĢtır. Bu kapsamda ISO/IEC 19770 standartları incelenmiĢtir. Yazılımlar IT‟nin bir parçası olduğu ve IT yönetimi ile yazılım varlıklarının yönetimi birçok yönde paralellik sergilediği için IT yönetimi konusunda uluslararası bir standart olan ITIL Kütüphanesi incelenmiĢtir.
(alan bilgisini) daha iyi görebilmemiz, ontolojinin temelini oluĢturan kavramları tespit edebilmemiz için TÜPRAġ BSM ile birlikte bir kavram haritası geliĢtirilmiĢtir. Bu kavram haritası geliĢtirilecek ontolojilerin temelini oluĢturmakta, bir yol gösterici olarak rol almaktadır. Son aĢamada, tüm incelenen standartlar, geliĢtirilen kavram haritası ve süreç boyunca edinilen bilgiler ıĢığında basit bir “baĢlangıç ontolojisi” geliĢtirilmiĢtir. Bu ontoloji, ilerleyen süreç içerisinde iteratif olarak geliĢtirilerek RBT varlıkları ontolojisinin bir parçası olacaktır. Ġlerleyen kısımlarda, yaĢanılan süreç, her konu bir ana baĢlıkta olmak üzere, ayrıntılarıyla anlatılacaktır.
Bu kısımda tezimizin paralel yürüdüğü TÜPRAġ‟ın RAFĠNERĠ BĠLGĠ TEKNOLOJĠSĠ VARLIKLARININ ONTOLOJĠ TABANLI ĠZLENMESĠ VE YÖNETĠMĠ isimli projesi hakkında bilgi verilecektir. Projeye İhtiyaç Duyulmasının Nedeni (TÜPRAġ BSM, 2010, s. 8) RBT varlıkları çok çeĢitli ve sayıca çok fazladır. Aralarında çok fazla iliĢki vardır. Her birim/kiĢi sadece kendi sorumlu olduğu kısım konusunda teknik bilgiye sahiptir. Eğer bir yerde bir problem çıkarsa veya bir birim sorumlu olduğu sistemin hatalı çalıĢtığını düĢünürse kendi çözümlerini bulmaya çalıĢırlar. Ancak farklı sistemler arasındaki iliĢkiler net olarak tanımlanmamıĢtır. Bu yüzden bir sistemdeki arızanın diğer birimleri nasıl etkileyeceği veya bir sisteme yapılan değiĢikliğin diğer hangi sistemleri etkileyeceği kesin olarak bilinememektedir. Bir sistemin elemanları izleme yazılımları ve sorumlular tarafından izlenmektedir, ancak sistemler arası iliĢkiler izlenememektedir. Bu, çözümlerde ortak çalıĢma verimliliğinden faydalanılmasını engellemekte, sorunları araĢtırmak zaman kaybına neden olmaktadır. Projenin Amaçları (TÜPRAġ BSM, 2010, s. 8) Rafineri süreçlerini doğru verilerle çalıĢtırmak Rafineri süreçlerini aksatmamak (süreklilik) Arızi durumlarda mühendislik maliyetlerini azaltmak Sistemin güvenirliğini yüksek tutmak Projenin Çıktıları (TÜPRAġ BSM, 2010, s. 15) Yapılacak etki analizi ile bir bakım veya yatırım çalıĢmasından önce etkilenecek varlıklar belirlenebilecektir.
ana sebebi hızlı Ģekilde bulunarak problem büyümeden çözülebilecektir. RBT, birbirinden farklı birçok teknoloji bir üst katmanda birleĢtirilerek kullanılan teknoloji bağımlılığından arındırılacaktır.
yönetilebilmesi için öncelikle IT‟nin nasıl yönetildiği anlaĢılmalı ve yönetim biçimi elden geçirilmelidir. Bu yüzden bu tez kapsamında IT‟nin yönetim Ģekli ile ilgili standartlardan ITIL incelenmiĢ ve bu konuda bilgi sahibi olunmuĢtur. ITIL Nedir? ITIL, Information Technology Infrastructure Library açılımına denk gelmektedir. IT servislerinin ve yapılanmasının tamamının yönetimi için geliĢtirilmiĢ oldukça geniĢ çaplı ve ayrıntılı bir metodolojidir. Bilgi Teknolojisi Altyapı Kütüphanesi olarak TürkçeleĢtirilebilir. (Vikipedi, 2010) ITIL Ġngiliz Ticaret Bakanlığı (Office of Government Commerce) tarafından geliĢtirilmiĢtir. Ġçerik olarak en iyi uygulamaları / en iyi deneyimleri (best practices) konu almaktadır. ġimdiye kadar üç sürümü yayımlanmıĢ olan ITIL dünyada yaygın olarak kullanılmakta olup standart olarak kabul görmüĢ ve benimsenmiĢtir. (Vikipedi, 2010) ITIL’a Neden İhtiyaç Vardır? Günümüzde insanların istekleri ve buna bağlı olarak market çok hızlı bir Ģekilde değiĢmektir. Marketten pay alabilmek için bu değiĢime en hızlı Ģekilde cevap vermek bir ihtiyaçtan öte zorunluluktur. DeğiĢikliklere hızlı cevap verebilmek için, iyileĢtirmeleri ve yenilikleri hızlı bir Ģekilde hayata geçirebilmek gerekir. Bu da her gün büyüyen ve yapısı daha da karmaĢıklaĢan IT‟nin hızlı bir Ģekilde değiĢikliklere ayak uydurması ile mümkün olur. (APM Group Limited, 2010, p. 4) Günümüz Ģirketlerinin belirgin bazı ihtiyaçları vardır: (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 4) IT ve yapılan iĢ için stratejik planlar kurulabilmesi Yapılan iĢ ile IT‟nin hedeflerinin aynı çizgide gidebilmesi Sürekli iyiye gitme IT yapısının iĢlerliğinin ve etkinliğinin ölçülmesi Yapılan yatırımlardan elde edilen sonuçların belirebilmesi
belirlenebilmesi Daha çok projenin baĢarılı bir Ģekilde teslim edilmesi DıĢarıdan almanın mı, geliĢtirmenin mi daha avantajlı olduğunun belirlenebilmesi IT sayesinde rekabet ortamı yaratabilmek Projelerin zamanında ve belirlenen harcamalarla tamamlanabilmesi Sürekli değiĢimin yönetilebilmesi Bu problemlerin hepsi, doğru bir IT organizasyonunun baĢarılı bir Ģekilde uygulanabilmesi ve iĢ katmanı ile organize çalıĢılması sayesinde gerçekleĢtirilebilecek hedeflerdir. ITIL, bu gereksinimleri karĢılayabilecek bir IT organizasyonu oluĢturmak ve IT‟yi yönetebilmek için önerilen fonksiyonlardır. ITIL temel olarak aĢağıdaki kazançları sağlamaktadır: IT servislerinin hizmetlerinden daha memnun müĢteri/kullanıcı. Daha kaliteli bir servis. Azalan iĢ tekrarı, azalan kayıp zaman ve iyi kaynak yönetimi kaynaklı bütçede tasarruf. Yeni ürünleri/hizmetleri daha hızlı sunabilmek. Daha kolay karar verebilmek, daha az risk almak. ITIL’ın Tarihçesi ITIL‟ın ilk sürümü 1987'de çıkmıĢ ve ilerleyen seneler boyunca yapılan eklemelerde toplamda 30 kitaptan oluĢan bir sete dönüĢmüĢtür. Bu kadar büyük bir set, hem okunup uygulanabilmesi hem de maddi açıdan ciddi sorunları beraber getirmiĢtir. (Wikipedia, 2011, p. #History) ITIL versiyon 2, 2001 yılında yayımlanmıĢtır. Birinci sürümden farklı olarak kitaplar “mantıksal bölümlere” ayrılmıĢtır. ITIL versiyon 2, 8 süreci içeren 8 kitap halinde yayımlanmıĢtır. (Wikipedia, 2011, p. #Overview_of_the_ITIL_v2_library) Üçüncü sürüm 2007 yılında yayına alınmıĢtır. Üçüncü sürüm bir giriĢ ve 5 temel kitap olarak yayınlanmıĢtır. Kitap sayısı azaltılarak bölümlendirmenin basitleĢtirilmesi, standardın incelenip anlaĢılmasını ve uygulanmasını daha kolay hale getirmiĢ ve yaygınlaĢmasını sağlamıĢtır. Bu sürüm IT içerisindeki varlıkların
açıdan yaklaĢmaktadır. (ITIL Central) OGC 2009 yılında yaptığı resmi bir açıklama ile artık ITIL v2 sertifikasyonlarının değer taĢımayacağını duyurmuĢ ve ITIL v3‟e geçiĢ konusunda nasıl ilerlenmesi gerektiği ile ilgili danıĢmanlık hizmetleri sunmuĢtur. (Office of Government Commerce) ITIL v2 ITIL v2 2001 yılında çıkmıĢtır. ITIL‟ın bu sürümü 8 temel bölümden oluĢmaktadır. Bu bölümler aĢağıda listelenmiĢtir: (Wikipedia, 2011, p. #Overview_of_the_ITIL_v2_library) Service Support Service Delivery ICT Infrastructure Management Security Management The Business Perspective Application Management Software Asset Management Planning to Implement Service Management Bu isimler, hem orijinaline sadık kalmak için hem de Türkçeye çevrildiğinde anlamsal karĢılığı birebir verilemediği için Ġngilizce tutulması uygun görülmüĢtür. Ġlerleyen kısımlarda tüm bölümler ayrı ayrı anlatılacaktır. Service support IT‟nin bu kısmı, ITIL‟a göre kullanıcılara servis desteği sağlamakla görevlidir. Kullanıcıların kullandıkları sistem/yazılımlardaki değiĢiklik istekleri, yaĢadıkları zorlukların giderilmesi, destek birimleriyle iletiĢim ihtiyaçları, arızaların çözülmesi istekleri burada karĢılanır. (Wikipedia, 2011, p. #Service_Support) ITIL‟a göre, IT‟nin servis sağladığı Ģirket için kurumlar ve/veya Ģirket dıĢındaki son kullanıcıların tamamı, IT'nin “müĢterisidir”. “Service Support” IT‟nin destek kanalı olarak dıĢarıya “tek bir iletiĢim noktası” Ģeklinde görülür.
Service Desk Incident Management Problem Management Change Management Release Management Configuration Management Service desk Bu servis yaĢanan problemlerin IT‟ye raporlanması için tek giriĢ ve çıkıĢ noktasıdır. Gelen problemler “Incident Management”‟e yönlendirilmektedir. Service Desk, günümüz çağrı merkezleri gibi düĢünülebilir. Örneğin AVEA 500, Avea‟nın IT servisleri için müĢterinin tek giriĢ noktasıdır. Geri bildirimlerin tamamı da yine bu nokta aracılığı ile yapılmaktadır. (Wikipedia, 2011, p. #Service_Desk_.2F_Service_Request_Management) Incident Management Bu servis yaĢanmıĢ ve “Service Desk” tarafından raporlanmıĢ bir problemi en kısa sürede çözmeye çalıĢır. Burada temel amaç, sıkıntının en kısa sürede ve en az yan etki ile çözülmesi böylece kullanıcıların çok fazla zarar görmemesini sağlamaktır. Sorunlara hızlı bir Ģekilde cevap verilebilmesi müĢterinin mali kaybı olmaması açısından önem taĢımaktadır. (TeamQuest) (Wikipedia, 2011, p. #Incident_Management) Problem Management Problem management servisinde “Incident Management”te acilen çözülmeye çalıĢılan problemin kaynaklandığı asıl neden bulunmaya çalıĢılır. Burada amaç, yaĢanmıĢ problemlerin kök nedenlerinin tespit edilmesidir. Böylelikle sorun düzeltilebilecek, aynı sorunlar tekrarlanmayacaktır. Sorun düzeltilmese bile nedeni biliniyor olacaktır. (IT Process Maps, 2010)
yöntemlerle çözmeye çalıĢırken, Problem Management bunun temellerini araĢtırır. Incident Management‟te hız kritik iken, Problem Management daha uzun süreli araĢtırmaların yapıldığı bir servistir. Bu iki servis arasındaki farkı ortaya koymak için aĢağıdaki örnek verilebilir: Bilgisayarda bir arıza sonucu mavi ekran hatası alındığında “yeniden baĢlatınız” diyerek, problemi hızlıca çözen kiĢi “Incident Management” yapmaktadır. Alınan mavi ekran hatasının sebebini araĢtıran ve hangi sürülerin bozuk olduğunu keĢfeden ekip ise “Problem Management” yapmaktadır. Nedeni bulunan problemlerin çözümlenmesi Problem Management‟in görevleri içerisinde yer almamaktadır. Problem Management servisi içerisinde sıkça kullanılan iki kavram vardır: Problem: Nedeni bilinmeyen arıza. (Wikipedia, 2011, p. Problem_Management) Known Error: Nedeni bilinen, ancak henüz gerekli düzeltilmeler yapılmamıĢ arıza. (Wikipedia, 2011, p. Problem_Management) Change Management IT içerisinde değiĢikliklerin yönetimi bu kısımda yapılmaktadır. DeğiĢiklik yapılacak ögelerin diğer ögelere olan bağımlılıklarının belirlenmesi, servislerin en az zarara/kesintiye uğrayacak Ģekilde değiĢikliğin yapılmasının sağlanması, değiĢikliğin maliyetinin kontrol edilmesi ve değiĢikliğin yapılmasının ardından yapılan kabul testleri ve kalite kontrol yine bu kısmın sorumluluğu altındadır. (TeamQuest) (Wikipedia, 2011) Release Management Release Management, Change Management ile sıkı sıkıya bağlı bir disiplindir. Yeni yazılım/donanımların yayına alınması veya güncellemelerin yapılmasından sorumludur.
iĢlemi esnasında veya hemen sonrasında çıkabilecek problemler ile ilgili çözüm yöntemleri belirlenmelidir. (TeamQuest) (Wikipedia, 2011, p. #Release_Management) Configuration Management Konfigürasyon Yönetimi, IT bünyesindeki tüm Configuration Item (CI)‟ların bir listesinin tutulmasını görev almaktadır. CI‟ların bilgileri bir veritabanında tutulmalıdır. Bu veritabanına CMDB (Configuration Management Database) adı verilir. Bu veritabanının içerisindeki bilgilerin doğru ve güncel olması da yine bu disiplinin görevlerindendir. (TeamQuest) CI: Tek bir parça halinde yönetilebilecek her Ģeydir. Buna tek parça halinde yönetilebilecek (bunun için yazılmıĢ/yapılandırılmıĢ) yazılım, yazılım parçaları, donanımlar, dokümanlar, modeller, planlar ve kiĢiler dahil edilebilir. (Wikipedia, 2011) Bir CI‟ın büyüklüğü ufak bir mikroçipten içerisinde birçok donanım bulunduran büyük bir sunucuya kadar her ölçüde olabilir. (ISO/IEC, 2006, p. 3) Konfigürasyon Yönetimi‟nin yapılması ile IT kaynaklarını ve kaynakları arasındaki bağımlılık, iliĢkileri biliyor hale gelecektir. (TeamQuest) Service delivery ITIL‟ın bu kısmı, “Business” kullanıcılarına iĢlerini yürütebilmeleri için gerekli servisleri sağlamalıdır. ġirketin iĢ yapabilesi için gerekli olan araçların sağlanması, ihtiyaçların karĢılanması bu kısım altında olur. (Wikipedia, 2011, p. #Service_Delivery) IT‟nin diğer Ģirket departmanlarını birer müĢteri olarak gördüğü unutulmamalıdır. “Service Delivery” çeĢitli alt parçalardan oluĢmaktadır: Service Level Management Capacity Management IT Service Continuity Management Availability Management
Service Level, “ölçülebilen hizmet kalitesi” anlamına gelmektedir. IT‟nin verdiği hizmetin derecesi ve kalitesinin belirli metriklerle ölçülebilmesi ve kayıt altına alınması için çeĢitli “Servis Seviyeleri” belirlenebilir. Örneğin bir hosting firması için, “aylık en fazla 30 dakikalık sunucu kesintisi" bir servis seviyesidir. IT ile diğer departmanlar veya son kullanıcılar arasında bir SLA (Service Level Agreement) veya OPA (Operational Level Agreement) anlaĢması yapılabilir. Bu, IT‟nin vereceği servisin kalitesini garanti altına alır ve SLA‟ya uyulmadığında bunun yaptırımları önceden belirlenmiĢ olur. SLA‟nın karĢılanması konusunda Sevice Level Management Availability Management, Capacity Management, Incident Management ve Problem Management ile birlikte çalıĢıp Financial Management‟in verdiği kaynaklarla SLA‟ya uyulmasını sağlarlar. (Wikipedia, 2011, p. #Service_Level_Management) Service Level Management kapsamında IT‟nin sunabileceği servis seviyelerinden oluĢan bir “Service Catalog” da sunulur. (TeamQuest) Capacity management IT servislerinin yeterli kapasiteye sahip olduğun garanti altına alınmasını kapsamaktadır. Bu yapılırken, minimum maliyet ile maksimum verim alınması için gereken düzenlemelerin yapılması da Capacity Management ile ilgilidir. (Wikipedia, 2011) Örneğin, sunucuların yük durumları gözlenmeli ve sunucuların iĢlem güçlerinin SLA‟ları karĢılayabilecek yeterlilikte olduklarından emin olunmalıdır. IT service continuity management Sistemlerin izlenmesi ve sürekli olarak çalıĢır halde olmasını kapsamaktadır. Büyük ve ani felaketlerde (deprem tsunami, nükleer sızıntı vs.) dahi bu
kapsamında planlanmalıdır. (TeamQuest) Bunun için risk yönetiminin gerçekleĢtiriliyor olması, acil durumlarda uygulanacak stratejilerin hazır olması ve öncelikli kurtarılacakların ve buna benzer Ģeylerin belirli olması gerekmektedir. (TeamQuest) Bir bankanın acil durumlar için farklı bir Ģehirde veri merkezi kurması IT Service Continuity Management‟e örnek verilebilir. Availability management IT servislerinin varlığının devamlılığının sağlanmasını kapsamaktadır. IT‟nin güvenilirliği, güvenliği, sahip olduğu sistemlerin bakımının sağlanması gibi hizmetlerle alakalı iĢler bu süreç altında gerçekleĢtirilir. Böylece IT sözünü vermiĢ olduğu SLA‟lara uyabilir. (IT Process Maps, 2010) Financial management for IT services IT‟nin yaptığı iĢlerin, sağladığı servislerin Ģirket tarafından belirlenen ve sağlanan bütçeye uygun olarak gerçekleĢtirilmesi için bütçenin yönetiminin yapılmasını kapsayan kısımdır. (Wikipedia, 2011, p. #Financial_Management_for_IT_Services) ICT infrastructure management ITIL‟a göre, IT‟nin genel yapılanması burada anlatılan esaslara göre düzenlenmelidir. (Wikipedia, 2011, p. #ICT_Infrastructure_Management) Bu kısım dört alt baĢlıktan oluĢmaktadır: ICT Design and Planning ICT Deployment ICT Operations ICT Technical Support ICT design and planning IT‟nin yapılandırılmasının “business” kısmının gereksinimlerini karĢılayacak Ģekilde Ģekillendirilmesini kapsar.
cihazı yerine cep telefonlarına geçiĢ yapabilir. (TeamQuest) ICT deployment IT yapılandırılması için karar verilen değiĢikliklerin en az zararla yapılmasını sağlamak bu bölümün konusudur. (TeamQuest) Örneğin, çağrı cihazından cep telefonuna geçildiğinde Ģirket çalıĢanlarına cep telefonunun nasıl kullanıldığı ile ilgili eğitim verilerek, öğrenme sürecinin olumsuz etkileri azaltılabilir. ICT operations Bu kısım IT‟de iĢlerin yolunda gitmesi ile ilgilenmektedir. ICT yapısının sağlamlığı, tüm alınan kararların ve olayların kayıt altına alınması, iĢlerin dağıtılması ve zamanlanması, IT ile ilgi veri tabanlarının ve bilgilerin yönetilmesi ile yedeklenmesi yapılan temel iĢlerdendir. (TeamQuest) ICT technical support Bu kısım IT içindeki teknik servis ve danıĢılacak uzman anlamına gelir. (TeamQuest) Örneğin, IT'de çalıĢan bir kiĢinin bilgisayarı arızalandığında baĢvurduğu nokta bu birimdir. Bu kısım sadece basit teknik problemlerle ilgilenmez, yapılan iĢle ilgili uzmanları da barındırır ve danıĢmanlık da yapar. Örneğin bir yazılım mühendisi kullanacağı API‟ler ile ilgili yardım veya öneriye ihtiyaç duyarsa buradaki profesyonellerden yardım alabilir. Security management ITIL‟ın güvelik yönetimi kısmı, ISO/IEC 27001 standardı temel alınarak geliĢtirilmiĢtir. Bu kısmın amacı bilginin “bilmesi gereken kiĢiler” dıĢındaki kiĢi ve kuruluĢlara ulaĢmasını engellemektir. (Wikipedia, 2011, p. #Security_Management) Güvenliğin sağlanması için kural ve prosedürler oluĢturulmalıdır. Bu kural ve prosedürler herkesin anlayabileceği kadar açık olmalı ve uyulmadığı takdirde Ģirketin uğrayacağı zararlar anlatılmalıdır. (TeamQuest)
incelenmesi gereken bir standart olduğundan bu tez kapsamına alınmamıĢtır. The business perspective Bu grup, “ĠĢ Katmanı” ile “IT” arasında yer almaktadır. ĠĢ kısmının isteklerini alır, bunları IT‟nin gerçekleĢtireceği dönüĢtürür. ĠĢ katmanının istediklerinin maliyetinin yaklaĢık ne kadar olduğunu ve bu maliyeti üstlenip istenileni gerçekleĢtirmenin “değip değmeyeceğini” hesaplar. Bunları yönetime sunar. The Business Perspective takımındakiler Ģirketin yaptığı iĢi bilirler. Sadece teknik konuda bilgili değillerdir. Bu takım gelen iĢ katmanından gelen istekteki amacı inceler. ġirketin gelecekte izleyeceği stratejiyi yorumlar ve bir rapor oluĢturur. (TeamQuest) Örneğin bir banka, mortgage iĢlemlerinin daha hızlı yapılabilmesi için yeni bir yazılıma ihtiyaç duyar. Bu iĢ katmanından IT‟ye Business Perspective ile iletilir. Business Perspective bu isteği maliyet ve gereklik açısından inceler. Banka, örneğin, üç yıl içerisinde mortgage pazarından çekilmek düĢüncesindeyse bu iĢin gereksiz olduğuna karar verebilir. Eğer banka mortgage konunda büyümek istiyorsa bu istek uygundur. Application management Bu kısım, iĢ katmanı için geliĢtirilen yazılımların yaĢam döngüsünden sorumludur. Yazılımların geliĢtirilme süreci, yönetilmesi, iyileĢtirilmesi ve zorunlu durumlarda emekli edilmesi bu takımın iĢidir. (TeamQuest) Bu kısım aynı zamanda bir yazılımın yaĢam sürecinin çeĢitli aĢamaları da olan alt parçalardan oluĢmaktadır: Requirements Design Build Deploy Operate Optimize Bu parçaların ayrıntılarına konu dıĢı olduğu için değinilmeyecektir.
Ģekilde yönetilmesidir. Varlıklar baĢarılı bir Ģekilde yönetildiğinde: IT‟nin giderleri azaltılır. Gereksiz personel fazlalığı önlenmiĢ olur. Gereksiz yazılım fazlalığı önlenmiĢ olur. Her Ģey prosedürlere ve standartlara bağlı, açık ve net olur. SAM, insanlar, iĢ akıĢları ve teknolojiyi bir potada eritir. Temelde yazılım lisanslamaları, yazılım envanterlerinin yönetimi ve yazılımların geliĢtirme/satın almadan, terkine kadarki yaĢam döngülerinin yönetimini gerçekleĢtirmektedir. ISO/IEC 19770 standardı ile SAM çok detaylı bir Ģekilde incelenecektir. Planning to implement service management Bu kısım IT‟nin sürekli iyileĢmesine olanak sağlamak için vizyon yaratmakla sorumludur. Organizasyonun yapısı incelenerek, gelecek dönemler için hedefler konulur ve bu hedeflere ulaĢılması için gerekli çabayı sarf eder. (Wikipedia, 2011, p. #Planning_to_Implement_Service_Management) ITIL v3 ITIL v3 2007 yılında çıkmıĢtır. ITIL‟ın bu sürümü 5 temel bölümden oluĢmaktadır. Bu bölümler aĢağıda listelenmiĢtir: (Wikipedia, 2011, p. #Overview_of_the_ITIL_v3_library) Service Strategy Service Design Service Transition Service Operation Continual Service Improvement ITIL v3‟ün bir bakıĢta özetlenmiĢ hali için bkz. Ek 1: Bir Bakışta ITIL v3 Süreçleri s. 103 Bu isimler, hem orijinaline sadık kalmak için hem de Türkçeye çevrildiğinde anlamsal karĢılığı birebir verilemediği için Ġngilizce tutulması uygun görülmüĢtür. Ġlerleyen kısımlarda tüm bölümler ayrı ayrı anlatılacaktır.
belirlerken e bu servisleri sağlarken izlenecek yol ile ilgili stratejiler geliĢtirmektir. IT‟nin belirli bir düzen ve strateji altında çalıĢarak en verimli yolla en iyi sonucu alması Service Strategy‟nin sorumluluğundadır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 12) IT sunduğu servislerle müĢterilerini memnun etmeli, fark yaratmalıdır. Sürekli yarıĢ halinde olduğunu unutmamalıdır. Service Strategy aĢağıdaki sorulara cevap arar: MüĢteri kim? MüĢteri tam olarak ne istiyor? Hangi servisleri sunmalıyız? Bununla ilgili market ne durumda? Bu iĢin getirisi olur mu? Diğerlerinden farkımız ne? Nasıl tercih ediliriz? Performansımız nasıl ölçülebilir hale getirilebilir? Eğer yazılımı dıĢarıdan alma/kendi geliĢtirme imkânı varsa, müĢteri neye göre karar verir? Service Strategy dört alt bölümden oluĢmaktadır: Strategy Generation Financial Management Service Portfolio Management Demand Management Strategy generation MüĢteri için uzun vadede baĢarıyı getirecek stratejilerin yaratılmasını kapsamakta olup birçok alt parçadan oluĢan oldukça geniĢ bir konudur. (ITIL Frameworks, 2010) Financial management IT bütçesinin ayarlanması, muhasebe ve ürünlerden ücret alımı gibi konularla ilgilenmektedir. (IT Process Maps, 2010)
yatırım yapılıp hangilerine yapılmayacağına karar verildiği “ürün pörtföyü”nün belirlendiği kısımdır. (Wikipedia, 2011, p. #Overview) Demand management IT‟ye olan isteğin, gereksinimin akılcı bir Ģekilde değerlendirilmesi ve bu isteğin belirlenmesi için gerekli araĢtırmaların yapılmasını kapsar. (Wikipedia, 2011) IT‟nin aslında hiç gerekmeyecek, ihtiyaç duyulmayacak bir Ģeyle uğraĢması gereksiz ve vakit kaybıdır. Örneğin Unit Test yapılmayan bir firma için IT‟nin Unit Test Toolları geliĢtirmesi garip karĢılanır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 16) Ayrıca iĢler az olduğunda fiyat indirimi ile gelen iĢ sayısının artırılması gibi Ģeyler de istek yönetiminin içerisinde yer almaktadır. ITIL kapsamında Demand Management IT için yapılır, ancak normalde Demand Management tüm Ģirket için yapılabilecek baĢlı baĢına bir yönetimdir. Service design IT servislerinin hem Ģu anda kaliteli olabilmesi hem de gelecekte kaliteli kalabilmesi için gerekli tüm mimari yapı, kuralları, prosedürleri ve dokümantasyonu kapsar. Performans ölçümleri gerçekleĢtirmek ve anlaĢmalarla belirlenen servis seviyesini (SLA) sağlamak bu bölümün görevidir. Çıkabilecek problemlere hazırlıklı olmak amacıyla risk analizleri yapılması da Service Design‟a dahil edilebilir. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 18) ÇeĢitli alt parçalardan oluĢmaktadır: Service Catalogue Management Service Level Management Capacity Management
Information Security Management Supplier Management Service catalogue management Servis kataloğu sağlanan tüm servislerle ilgili doğru ve güncel bilgileri tutan bir kütüphanedir. Bu kütüphaneye hem çalıĢmakta olan, hem de gelecekte yayına alınacak, Ģu an geliĢtirme aĢamasında olan IT varlıkları dahil edilmelidir. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 19) Servis kataloğu yapılan tüm iĢlerle ilgili bilgiler sahi olmalıdır. Bu bilgilere servis durumları, sunulan servis seviyeleri ve servisler arası iliĢki/bağımlılık bilgileri dahildir ancak bunlarla sınırlı değildir. (IT Frameworks, 2010) Service level management Service Level, “ölçülebilen hizmet kalitesi” anlamına gelmektedir. IT‟nin verdiği hizmetin derecesi ve kalitesinin belirli metriklerle ölçülebilmesi ve kayıt altına alınması için çeĢitli “Servis Seviyeleri” belirlenebilir. Örneğin bir hosting firması için, “aylık en fazla 30 dakikalık sunucu kesintisi" bir servis seviyesidir. IT ile diğer departmanlar veya son kullanıcılar arasında bir SLA (Service Level Agreement) veya OPA (Operational Level Agreement) anlaĢması yapılabilir. Bu, IT‟nin vereceği servisin kalitesini garanti altına alır ve SLA‟ya uyulmadığında bunun yaptırımları önceden belirlenmiĢ olur. SLA‟nın karĢılanması konusunda Sevice Level Management Availability Management, Capacity Management, Incident Management ve Problem Management ile birlikte çalıĢıp Financial Management‟in verdiği kaynaklarla SLA‟ya uyulmasını sağlarlar. (Wikipedia, 2011, p. #Service_Level_Management) Service Level Management kapsamında IT‟nin sunabileceği servis seviyelerinden oluĢan bir “Service Catalog” da sunulur. Bu sunulan katalog Service Catalogue Management kapsamındadır.
taĢımaktadır. (IT Process Maps, 2010, p. #Service_Level_Management) Capacity management IT servislerinin düzgün hizmet verebilmek ve SLA‟ları karĢılayabilmek için yeterli kapasiteye sahip olduğun garanti altına alınmasını kapsamaktadır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 20) ITIL v3‟ün bu kısmı ITIL v2 ile ciddi benzerlikler taĢımaktadır. (IT Process Maps, 2010, p. #Capacity_Management) Daha ayrıntılı bilgi için bkz. Capacity management s. 11 Availability management IT servislerinin varlığının devamlılığının sağlanmasını kapsamaktadır. IT‟nin güvenilirliği, güvenliği, sahip olduğu sistemlerin bakımının sağlanması gibi hizmetlerle alakalı iĢler bu süreç altında gerçekleĢtirilir. (IT Process Maps, 2010) ITIL v3‟ün bu kısmı ITIL v2 ile ciddi benzerlikler taĢımaktadır. (IT Process Maps, 2010, p. #Availability_Management) IT service continuity management Sistemlerin izlenmesi ve sürekli olarak çalıĢır halde olmasını kapsamaktadır. Büyük ve ani felaketlerde (deprem tsunami, nükleer sızıntı vs.) dahi bu sürekliliğin sağlanması için gereken planlar IT Service Continuity Management kapsamında planlanmalıdır. (TeamQuest) Bunun için risk yönetiminin gerçekleĢtiriliyor olması, acil durumlarda uygulanacak stratejilerin hazır olması ve öncelikli kurtarılacakların ve buna benzer Ģeylerin belirli olması gerekmektedir. (TeamQuest) ITIL v3‟ün bu kısmı ITIL v2 ile ciddi benzerlikler taĢımaktadır. (IT Process Maps, 2010, p. #IT_Service_Continuity_Management) Daha ayrıntılı bilgi için bkz. IT service continuity management s.11
standardı temel alınarak geliĢtirilmiĢtir. Bu kısmın amacı bilginin “bilmesi gereken kiĢiler” dıĢındaki kiĢi ve kuruluĢlara ulaĢmasını engellemektir. (Wikipedia, 2011, p. #Security_Management) Güvenliğin sağlanması için kural ve prosedürler oluĢturulmalıdır. Bu kural ve prosedürler herkesin anlayabileceği kadar açık olmalı ve uyulmadığı takdirde Ģirketin uğrayacağı zararlar anlatılmalıdır. (TeamQuest) ITIL v3‟ün bu kısmı ITIL v2 ile ciddi benzerlikler taĢımaktadır. (IT Process Maps, 2010, p. #IT_Security_Management) Supplier management Sağlayıcılarla yapılan anlaĢmaların IT‟nin sunacağı hizmetleri karĢılamak için yeterli olacağını garanti altına almak ve sağlayıcının anlaĢmaya uyup uymadığını denetlemek bu kapsam içerisinde yer almaktadır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 22) Böylece IT hiçbir zaman malzeme eksikliğine düĢmez. Örneğin, IT bir hizmeti vermek için (örneğin sitenin portalı) bir sunucuya ihtiyaç duyabilir. Bu sunucu kiralanıyor olabilir. Satıcıdan sunucunun sürekli kiralanmasının kontrolü ve satıcının sunucu ile anlaĢmaya (mesela SLA) uyup uymadığının kontrolü bu bölüm içerisinde yapılır. Yönetim yapılabilmesi için sağlayıcılar ve imzalanan anlaĢmaları içeren Supplier Contact Database oluĢturulmalıdır. Service transition Service Transition, geliĢtirilmesi tamamlanmıĢ servislerin; testinden, çalıĢtığının onaylanmasından, çalıĢır bir sürümün yayına alınma sürecinden ve servislerle ilgili değiĢikliklerin yönetiminden sorumludur. Bunların gerçekleĢtirilebilmesi için yazılımın “Business” için değeri kavranmalı ve yazılımın bağlantılı olduğu herkes (stakeholders) bilinmelidir.
Change Management Release Management Evaluation Service Validation and Testing Service Asset and Configuration Management Knowledge management Bilgilerin sadece bilinmesi gerekenler tarafından bilinmesini sağlayacak bir dağıtım/koruma mekanizması kurulmasını içerir. Bilgi yönetiminde kiĢilerin istediği an ihtiyaç duyduğu bilgiye ulaĢabilmesi, böylece bilgi eksikliğinden dolayı iĢlerin aksamaması; ama herkesin her önüne gelen bilgiye ulaĢmasını engelleyecek yetki mekanizmasının da kurulmuĢ olması gerekmektedir. Bilgi yönetimi ile daha etkin ve kaliteli bir hizmet ve bilgi güvenliği sağlanmaktadır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 27) Change management Duyulan ihtiyaçlar çerçevesinde, hali hazırda çalıĢmakta olan servislere zarar vermeden değiĢiklik yapılmasıdır. Ġhtiyaçlar var olan yazılımlarda çıkan hatalar (bug) veya iĢ katmanının istediği yeni özellikler olabilir. Gelen değiĢiklik istekleri DeğiĢim Yönetimi çerçevesinde önceliklendirilir, finansal hesaplamalar yapılır, değiĢikliği yapmanın maliyet ve getirebileceği yük açısından değip değmeyeceğine karar verilir. Bunlar sonucunda değiĢiklik gerçekleĢtirilir veya vazgeçilir. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 25) DeğiĢim Yönetimi baĢlı baĢına ele alınması gereken oldukça geniĢ bir konudur. Release management Yeni veya güncellenmiĢ servislerin yayına alınmasını kapsar. Bu esnada, en az zarar ya da kesinti hedeflenmeli, hızlı olmalı, hatalar için backup planları olmalıdır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 27)
en az olduğu gece 02-04 arasında yapılması ve çıkabilecek problemlerde sitenin eski haline hemen dönülebilecek olması Release Management‟in iyi planlandığına örnek olabilir. Evaluation Sağlanan servisin Ģimdi değer taĢıdığı kadar gelecekte de “business” için değer taĢıması çok önemlidir. Bu yüzden bir servisin yararlı olup olmadığının kontrol edilmesi gerekir. Bu yüzden yararlılık esaslarını belirleyecek metrikler, değerlendirme ölçütleri gerekmektedir. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 28) Evaluation, bu ölçüm tekniklerini ve metrikleri belirlemektedir. Change Management değiĢime karar verirken bu ölçütlerden faydalanır. Continual Service Improvement süreci de belirlenmiĢ ölçütlerden sıkça faydalanmaktadır. (Accelerated Ideas) Service validation and testing ÇalıĢma ortamına alınmadan önce satın alınan/geliĢtirilen tüm ürünlerin “business requirement”ları karĢıladığından emin olmak son derece önemlidir. Bu testler Service Validation and Testing tarafından yapılmaktadır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 28) Bu kontroller iĢ bilgisi gerektirir. Aynı zamanda yapılmıĢ anlaĢmalar ve SLA seviyeleri de gereksinimlerin karĢılanıp karĢılanmadığı konusunda rehber olabilmektedir. Service asset and configuration management Servisleri sağlayabilmek için gerekli tüm varlıkların ve bunların konfigürasyonunun yönetimini sağlar. Böylece bu varlıkların arasındaki iliĢkiler bilinir. Yapılı konfigürasyonlar kayıt altına alınır, yapılan değiĢikliklerin loğları bulunur. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 26) Service operation Bu süreç servislerin ilk defa müĢteriye sunulmasından ve daha önce anlaĢılmıĢ servis seviyelerine uyulmasından sorumludur.
bu kısımda yer alır. Service Operation 5 baĢlık altına bölünebilmektedir: Event Management Incident Management Problem Management Request Fulfillment Access Management Event management Olay: IT servisini etkileyebilecek veya yapılandırma ile alakalı bir “state” değiĢimidir. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 29) Olayları direk CI‟lar yollayabilir (push) veya yazılımlarla arada bir CI‟lardan alınabilir. (pull) Olaylar normal olabilir. (Örnek: 00.00 Günlük yedek baĢladı.) Bu olaylar sadece loglanır. Ancak olması istenmeyen, beklenmeyen olaylar gerçekleĢirse bunlar incident‟a mahal verilebilir. (Örnek: ĠĢlemci sıcaklığı 100 dereceyi geçti!) Eventlere yanıtlar otomatik ya da manuel olabilir. (Örneğin iĢlemci 100 dereceyi geçerse, veri merkezinin soğutması turbo moda geçer.) Aynı zamanda olaylar SMS ve benzeri yöntemlerle yetkililere haber de verilebilir. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 29) Incident management Incident: Beklenmeyen/ani bir sebeple hizmetin sekteye uğraması. (Disk bozuldu, internet bağlantısı koptu vs.) (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 30) Incident Management problemi en kısa sürede çözmeye çalıĢır. Böylelikle en az zararla sistem tekrar iĢler hale getirilir. Incident Management‟te çözümün kalıcı olması değil, hızlı olması önemlidir. (workaround) Sorunlara hızlı bir Ģekilde cevap verilebilmesi müĢterinin mali kaybı olmaması açısından önem taĢımaktadır. (TeamQuest) (Wikipedia, 2011, p. #Incident_Management)
Ģikâyetlerle anlaĢılır. Incident çözülemezse, teknik servise yönlendirilir. Onlar da kendi aralarında iĢin uzmanı ekibe yönlendirirler. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 30) Problem management Problem management servisinde “Incident Management”te acilen çözülmeye çalıĢılan problemin kaynaklandığı asıl neden bulunmaya çalıĢılır. Burada amaç, yaĢanmıĢ problemlerin kök nedenlerinin tespit edilmesidir. Böylelikle sorun düzeltilebilecek, aynı sorunlar tekrarlanmayacaktır. Sorun düzeltilmese bile nedeni biliniyor olacaktır. (IT Process Maps, 2010) Nedeni tespit edilen hatalar Change Management‟e iletilir. Düzeltilip düzeltilmeyeceği bu kısmın kanaatindedir. Incident Management yaĢanan sıkıntıyı hızlı bir Ģekilde ve geçici yöntemlerle çözmeye çalıĢırken, Problem Management bunun temellerini araĢtırır. Incident Management‟te hız kritik iken, Problem Management daha uzun süreli araĢtırmaların yapıldığı bir servistir. Problem Management servisi içerisinde sıkça kullanılan iki kavram vardır: Problem: Nedeni bilinmeyen arıza. (Wikipedia, 2011, p. Problem_Management) Known Error: Nedeni bilinen, ancak henüz gerekli düzeltilmeler yapılmamıĢ arıza. (Wikipedia, 2011, p. Problem_Management) Change Management nedeni bilinen ancak henüz düzeltilmemiĢ arızaların listesini Known Error Database adı verilen bir veritabanında tutar. Böylelikle insanların bu sorunlara geçici çözümler araĢtırabileceği bir bilgi bankası oluĢturulmuĢ olur. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 31) Request fulfillment Kullanıcıların IT‟ye yapmıĢ oldukları tavsiye, bilgi, değiĢiklik veya yeni bir IT servisine eriĢim isteklerinin hepsinin ulaĢtığı ve incelendiği noktadır. Bu
Windebank, & Rance, 2007, p. 30) Access management Hangi servise, hangi kullanıcıların eriĢebileceğinin belirlenmesi bu kısım altında yapılır. EriĢim yetkilendirilmesinde kiĢiler (authorization) ve roller (authentication) esastır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 31) Continual service improvement Amacı, sürekli değiĢen ĠĢ Katmanı ihtiyaçları ile IT servislerini birbirine bağlı tutmaktır. Sağlanan servisler iyileĢtirilerek sürekli amaca yönelik, iĢe yarayan servisler sağlanması sağlanır. (Cartlidge, Hanna, Rudd, Macfarlane, Windebank, & Rance, 2007, p. 35) ġirketlerde genellikle bir problem olmadan iyileĢtirme süreci baĢlamaz. CSI böyle olmaması için sürekli olarak gerçekleĢtiriliyor olmalıdır. CSI süreci genel olarak aĢağıdaki adımlardan oluĢmaktadır: Neyi ölçmeliyiz? Belirle. Ölçebilir miyiz? Karar ver. Verileri topla. Verileri iĢle. Analizleri yap: Hedeflere ulaĢıyor muyuz? GidiĢat ne yönde? ĠyileĢtirme için bir Ģeyler yapıldı mı? Maliyet durumu nedir? Bilgileri sun. Yetki al. ĠyileĢtirmeleri uygulamaya al.
2007, p. 35) Sürekli iyileĢmenin izlediği aĢamaları özetlemiĢtir: ġekil 1: Continual Service Improvement süreci Bir Özetle ITIL v3 Servislerin tasarımı (Service Design) ile baĢlayan süreç, servislerin yayına alınması (Service Transition) ile ve ardından yayında iken yapılan iĢler ile (Service Operation) devam etmektedir. Bir servis hayatı boyunca bu üç sürekte dolaĢmaktadır. Örneği değiĢiklikler için Service Operation‟dan tekrar Service Design‟a geri gelebilir. Tüm bu akıĢın nasıl olacağı ile ilgili planlamaların belirlendiği Service Strategy bu üç sürece içeriden dokunmaktadır. Bu akıĢın tamamının Business‟in ihtiyacı doğrultusunda olduğunu denetleyen ve bu konuda sürekli iyileĢmeyi öngören ve kesintisiz devam eden Continual Service Improvement ise en dıĢta tüm bu süreçleri sarmıĢtır. ITIL v3‟ün bu özetinin görselleĢtirilmiĢ hali için bkz. Ek 1: Bir Bakışta ITIL v3 Süreçleri s. 103 AkıĢı gösteren baĢka bir diyagram için bkz. Ek 2: ITIL v3 Süreçlerinin Akışı s. 104
bir Ģekilde yönetilmesidir. (Wikipedia, 2011) SAM, insanlar, iĢ akıĢları ve teknolojiyi bir potada eritir. Temelde, yazılım lisanslamaları, yazılım envanterlerinin yönetimi ve yazılımların geliĢtirme/satın almadan, terkine kadarki yaĢam döngülerinin yönetimini gerçekleĢtirmektedir. Yazılım Varlıklarını Yönetmenin Kazançları Nelerdir? Gider Kontrolü: Yazılım envanterlerinin tutulması ile eldeki yazılımlar bilinir. Böylece gereken kadar lisanslama yapılır. Etkin lisans kullanımı gider kontrolü sağlamaktadır. (Microsoft) Koca bir Ģirketin yazılım giderlerini hesaplamak, sadece gereken kadar lisans almak, bu lisansları en etkin Ģekilde kullanmak zordur. SAM ile kullanılan yazılımların tam bir envanteri tutulur. Bu envanter sayesinde kimin ne kullandığı ve nelere ihtiyaç duyduğu bilinir, sadece gereken kadar yazılım temin edilir. Lisans yönetimi sayesinde, lisanslara da gereğinden fazla para verilmesi ortadan kalkar. (Örneğin, Terminal baĢına lisanslama yerine Volume License almanın daha yararlı olduğu gibi çeĢitli çıkarsamalar SAM sayesinde yapılabilir.) Lisans Güvenliği: SAM sayesinde, her bilgisayara hangi yazılımların yüklendiği, kimlerin yüklediği ve kimlerin yükleme yetkisi olduğu gibi bilgiler yönetilebilmektedir. SAM, yazılımların lisanslama durumlarını da yönetebilmektedir. Tüm yazılımlar ve lisans durumlarının biliniyor olması, ansızın lisans problemi yaĢamayı ve hizmetlerin kesintiye uğramasını engeller. Aynı zamanda lisanssız yazılım kullanma ihtimali oradan kalkar. Tutular envanterler sayesinde fazla kurulum yapılmaz, yetkisiz kiĢiler de dıĢarıdan getirdikleri yazılımı kuramazlar. Bu da Ģirketin çok ciddi korsan yazılım cezalarından kurtulmasını sağlar.
riskler ilgili riskler önceden hesaplanabilir. Yazılımlar ile ilgili uyumsuzluklar, yazılım yoklukları, lisans bitimi problemleri, sunucu eriĢim izninin bitmesi gibi problemler daha gerçekleĢmeden yakalanır. Mutlu Personel: Personelin kullanacağı ve ihtiyaç duyacağı tüm yazılımlar kendisine hazır sunulur. Ġstekleri karĢılanmıĢ bir personel hem daha kolay çalıĢır, hem de mutlu olur. (Microsoft) İşler Daha Kolay Yürür: SAM yazılım varlıklarının yönetimi ile ilgili iĢlerin hepsinin belirli kurallar, standartlar ve prosedürlere göre yapılmasını Ģart koĢar. Herkesin görevi ve yetkileri bellidir. Yapılan tüm iĢler ne yapıldığı ve kim tarafından yapıldığı ile birlikte mutlaka kayıtlanır. (Microsoft) Böylece herkes kendine düĢeni, herkes tarafından bilinen prosedürlere göre yapıldığından iĢler çok daha hızlı, kolay ve hatasız yürür. Gerekmeyenler Kaldırılır: Yazılımlar bir defa satın alındıktan sonra, sistemlerde yapılan değiĢikliler için uyumluluk testleri, yazılım güncellemeler ve buna benzer Ģeylerden dolayı sürekli bakıma ihtiyaç duyar. Az kullanılan veya çok daha moderni çıkmıĢ bu yazılımları bazen sistemde tutarak sürekli bakım yapmak yerine, kaldırmak veya yenisini almak maliyeti azaltabilir. (Microsoft) SAM gereksiz yazılımları kaldırarak bakım maliyetlerinin azalmasını amaçlar. Değişikliklere Hızlı Ayak Uydurulur: SAM sayesinde yazılım ve yazılım varlıkları konusunda bir bilgi bankası oluĢturulduğundan, IT‟nin yönetimi, karar vermesi ve aldığı kararları uygulaması hem hızlanır hem kolaylaĢır. Böylece, değiĢen market isteklerine ve piyasaya Ģirket çok daha hızlı ayak uydurabilir. ISO/IEC 19770 Standartları ISO/IEC 19770 standartları yazılım varlıklarının yönetimi için geliĢtirilmiĢ uluslararası standartlardır. 19770 standartları üç kısımdan oluĢmaktadır:
nasıl organize edilmesi gerektiğini anlatır. ISO/IEC 19770-2: Her bir yazılım varlığının ayrı ayrı etiketlenebilmesi için gerekli olan “software identification tag” standardını tanımlar. Etiketler, tüm varlıkları birbirinden ayırmasının yanı sıra, yazılım varlığı hakkında bilgiler de sunabilir. (Sürümü, bağımlı olduğu yazılımlar, üretici vs.) ISO/IEC 19770-3: Yazılımların lisans bilgilerinin yönetimini sağlayacak bir standart olacaktır. ġu an geliĢtirilme aĢamasındadır. Bu yüzden proje kapsamında kullanılması mümkün olamamıĢtır. BaĢlığı “Software Entitlement Tag” olacaktır. (Wikipedia, 2011) ISO/IEC 19770-1: Processes Bir kuruluĢtaki yazılım varlıklarının belirli bir uluslararası standarda uygun Ģekilde yönetimini sağlamayı amaçlar. Yazılım varlıkları ile ilgili risk yönetimi yapılabilir. Yazılım varlıkları ile ilgili bir problem dolayısıyla; o IT hizmetlerinin kesintiye uğraması, o IT hizmetlerinde kalite düĢüĢü, o Bu problemlerden doğabilecek yasal yaptırımlar, o Bunlardan doğabilecek Ģirket imajı zedelenmesi engellenmiĢ olur. Yazılım giderleri etkin bir Ģekilde kontrol edilebilir. o SAM sayesinde, yazılım lisanslarının daha etkin kullanılır. Örneğin bazı lisans anlaşmaları satın alınan ürün için birden fazla kurulum izni verebilmektedir. Böyle durumlarda yeni lisans alarak para harcanmaz, olanlar değerlendirilir. o Daha önceden edinilen bilgiler bir arĢivde saklanacağından, hangi firmadan hangi yazılımın ne fiyatlarla alınabileceği konusunda bir bilgi sahibi olunur. Bu da hızlı bir Ģekilde ucuz yazılım alma imkânı sağlar. o Yazılım varlıklarının yönetilmesine yönelik giderler azaltılır. Çünkü yapılacak iĢler resmi bir doküman halinde önceden bellidir ve etkindir. o SAM kalitesi artınca çıkan problem azalır. Buna bağlı olarak hem Ģirket içi hem Ģirket dıĢı destek istekleri, bağlantılı olarak da destek giderleri azalır.
edilmiĢ bilgiler sayesinde çok daha hızlı ve doğru karar verilebilir. Çünkü bir bilgi bankamız var. o Bu sayede pazarın durumuna ve yeni isteklere daha çabuk cevap verilebilir. o SAM sayesinde problemler azalır. Bu da yüksek motivasyon, çok iĢ getirir. IT servisleri daha kolay yönetilebilir. Bir firmanın SAM konusundaki ihtiyaçları uluslararası bir standarda uygun Ģekilde karĢılanmıĢ olur. BaĢka firmalarla bu standarttaki tanımlar kullanılarak anlaĢmalar imzalanabilir. (ISO/IEC, 2006, p. v) ISO/IEC 19770-1 dahilinde yönetilebilir yazılımlar nelerdir? 19770-1 kapsamında yönetilebilir yazlımlar, çalıĢtırılabilir yazılımlar ve çalıĢtırılamaz yazılımlar olarak iki baĢlık altında incelenir. ÇalıĢtırılabilir yazılımlar programlar ve iĢletim sistemleridir. ÇalıĢtırılamaz yazılımlar ise, yazı tipleri, sesler, grafikler, dokümanlar ve bunlara benzer yazılımlar sayılabilir. (ISO/IEC, 2006, p. 1) ISO/IEC 19770-1 dahilinde yönetilebilir yazılım varlıkları nelerdir? 19770-1 kapsamında yönetilebilir yazılım varlıkları birkaç kategoride incelenebilir. Yazılım kullanım hakları, yazılımın kendisi ve yazılımların kurulum için kullanılan kopyaları bu kategoriler arasındadır. Yazılım kullanım hakları arasında Ģirket tarafından geliĢtirilen yazılımlarda hak sahibi, satın alınan yazılımlarda ise lisanslar sayılabilir. Yazılımın güncellemeleri ve yamaları da yönetilebilen yazılım varlıklar arasında sayılmaktadır. (ISO/IEC, 2006, p. 1) 19770-1 dahilinde yönetilmesi gereken diğer varlıklar nelerdir? 19770-1 dahilinde yazılım varlığı olmasa bile, yazılımla doğrudan iliĢkili olan her varlık mutlaka yönetilmelidir. Örneğin, bir donanımın yazılım varlıklarının yönetilmesinde gerekli bir bilgisi varsa, bu mutlaka SAM kapsamına alınmalıdır. (Örnek: Üzerinde yazılım varlıkları bulunan bir sunucunun iĢlemci sayısı, sabit disk seri numarası...) Ancak
bakım yapıldığı gibi yazılım varlıkları ile doğrudan alakası olmayan bilgilerin yönetilmesi gerekli değildir. Yazılım varlıklarıyla alakalı olabilecek baĢka varlıklara örnek olarak, yazılımı kullanacak personelin listesi, yazılımın lisanslanmasının yapıldığı kiĢi sayısı gibi bilgiler verilebilir. (ISO/IEC, 2006, p. 2) ISO 19770-1‟de bu konu bir tablo halinde sunulmuĢtur. bkz. Ek 3: ISO 19770-1 Kapsamında Yazılımla İlgili Olmayan Hangi Varlıkların Yönetilebileceğine Dair Tablo s. 105 SAM Süreçleri SAM süreçleri genel olarak üç ana baĢlık altında toplanmıĢtır. Her biri kendi içerisinde alt süreçler içermektedir. Bu süreç ve alt süreçlerin neler olduğu aĢağıda özetlenmiĢtir: (ISO/IEC, 2006, p. 5) Organizasyonel Yönetim Süreçleri o Kontrol Birimleri Kurumsal Yönetim Süreci Roller ve Sorumluluklar Kurallar, Süreçler ve Prosedürler Yetkinlik o Planlama ve GerçekleĢtirim Süreçleri Planlama GerçekleĢtirim Ġzleme ve Gözden Geçirme Sürekli ĠyileĢme Ana SAM Süreçleri o Envanter Süreçleri Tanımlama Envanter Yönetimi Kontrol o Doğrulama ve Uyum Süreçleri Kayıt Doğrulaması Lisans Uyumu Güvenlik Uyumu Uyumluluk Doğrulaması o Operasyon Yönetim Süreçleri ve Arayüzleri
Servis Düzeyinde Yönetim Güvenlik Yönetimi SAM Ġçin Birincil Süreç Arayüzleri o YaĢam Döngüsü Süreç Arayüzleri DeğiĢiklik Yönetim Süreci Satın Alma Süreci Yazılım GeliĢtirme Süreci Yazılımı Yayına Sunma Süreci Yazılım ÇalıĢma Ortamına Dağıtma Süreci Arıza Yönetim Süreci Problem Yönetim Süreci Kullanımdan Kaldırma Süreci (ISO/IEC, 2006, p. 5) Bu süreçler ISO standardında tablo halinde gösterilmiĢtir. bkz. Ek 4: ISO 19770-1 Süreçlerinin Tablo Halinde Gösterimi s. 106 Özet halinde SAM süreçleri SAM süreçlerinin tamamı kısa bir özet halinde bu baĢlık altında tanıtılmıĢtır. Ġlerleyen kısımlarda ayrıntılarıyla anlatılacaktır. Organizasyonel yönetim süreçleri SAM'in planının oluĢturulması, bakımı ve yönetimi gibi yapısal ve yönetimsel SAM'in süreçlerini bu kısım içermektedir. Kontrol Birimleri: SAM için yönetim sistemini kurmak ve korumakla yükümlüdür. Planlama ve Gerçekleştirim Süreçleri: SAM‟in etkin ve verimli bir Ģekilde gerçekleĢtirilmesiyle yükümlüdür. Ana SAM süreçleri SAM planının gerçekleĢmesi için yapılacak asıl iĢlerdir. Yazılım varlıklarının belirlenmesi, envanterlerin oluĢturulması, iliĢkilerin belirlenmesi ve buna benzer Ģeyleri bu kısım içermektedir.
oluĢturulmasını, bunlarla ilgili kayıtların yaratılıp muhafaza edilmesini ve diğer SAM süreçlerindeki yazılım ve yazılım varlıklarıyla bütünlük sağlamak için veri yönetme fonksiyonlarını geliĢtirmesini amaçlar. Doğrulama ve Uyum Süreçleri: SAM kuralları, süreçleri ve prosedürlerinde meydana gelmiĢ hataları yakalamayı ve lisans kullanım hakları da dâhil olmak üzere yönetmeyi amaçlar. Operasyon Yönetim Süreçleri ve Arayüzler: SAM‟in hedeflerine ulaĢmak için gereken temel operasyonları gerçekleĢtirebilmeyi amaçlar. SAM için birincil süreç arayüzleri SAM kapsamındaki yazılımların satın alınması/geliĢtirilmesinden, Ģirketin yazılımı kullanmayı bırakmasına kadar olan yaĢam döngüsüne dair SAM süreçlerini bu kısım içermektedir. Yaşam Döngüsü Süreç Arayüzleri: ISO/IEC 19770-1'in bu bölümü bu yaĢam döngüsü süreçleri için SAM‟in gereksinimlerini belirtmektir. ISO/IEC 12207 ve ISO/IEC 20000'in temel yaĢam döngüsü süreçleriyle bağlantılıdır. Ġlerleyen kısımda SAM süreçleri ayrıntılarıyla ele alınacaktır. I. Organizasyonel yönetim süreçleri SAM planının oluĢturulması, bakımı ve yönetimi gibi yapısal ve yönetimsel SAM süreçlerini bu kısım içermektedir. a. Kontrol birimleri Kontrol birimlerinin hedefi, SAM için yönetim sistemini kurmak ve korumaktır. (ISO/IEC, 2006, p. 6) i. Kurumsal yönetim süreci Bu süreç ile hedeflenen, yazılım varlıklarının yönetilmesi gerektiğinin yönetim kurulu (veya benzer yetkideki kiĢiler) tarafından farkına varılması ve bunun sağlanması için gerekli mekanizmaların kurulmasıdır.
bazı departmanlarda uygulanacak vb.) Yönetim ile ilgili sorumlulukların hangi kiĢi/kiĢilere ait olduğu belirlenir. Yazılım ve yazılım varlıklarıyla iliĢkilendirilmiĢ riskler ve riskleri hafifletebilecek çözüm önerileri dokümante edilir, en az yılda bir güncellenir ve yönetim kurulu tarafından onaylanır. Risk dokümanı en azından aĢağıdaki konuları içermek zorundadır: Yasayla olabilecek uyumsuzlukları (Örneğin, şirketin bulunduğu sektöründe A yazılımı yasak olabilir veya SAM kapsamında personelin bazı bilgilerinin toplanması yasalara aykırı olabilir.) Lisanslamalarla ilgili problemleri (Lisans uyumsuzlukları), Hatalı bir SAM'den dolayı IT'nin iĢ yapamaması Hatalı bir SAM'den ötürü aĢırı para harcama (Örneğin, hatalı SAM sonucu, IT‟ye gelen teknik destek isteği artar, IT buna daha çok kaynak ayırır.) SAM'in yönetim hedefleri yönetim kurulu tarafından onaylanır ve en az yılda bir gözden geçirilir. (ISO/IEC, 2006, p. 5) ii. Roller ve sorumluluklar Bu süreç ile hedeflenen, yazılım ve ilgili varlıklarla alakalı rol ve sorumlulukların açık ve net bir biçimde tanımlanması ve etkilenmesi olası tüm personel tarafından okunup anlaĢılmasıdır. SAM owner, organizasyonun yazılım varlıklarıyla alakalı bütün Ģirket ilkeleri, prosedür ve süreçlerden sorumludur. SAM owner‟a atanan sorumluluklar aĢağıdaki görevleri içermelidir: SAM yönetiminin görevlerini belirlemek. SAM planının geliĢtirilmesini denetlemek. Yetkili merciler tarafından onaylanmıĢ SAM planının uygulanabilmesi için gerekli kaynakları ayarlamak. SAM planının sonuçlarını toplamak. Tüm yerel (kısmi) SAM yöneticilerinin kendilerine düĢen sorumlulukları yerine getirdiklerinden, SAM yöneticisi olmayan bir Ģirket bölümü olmadığından ve iki SAM yöneticisinin yetki alanlarının birbirleriyle çakıĢmadığından emin olmak. Yerel yöneticilere atanan sorumluluklar aĢağıdaki görevleri içermelidir:
SAM‟den elde edilen sonuçları toplamak. Kendisine verilen görev çerçevesinde gerekli prosedür, iĢ akıĢı ve kuralları uygulamaya koymak. Yazılım ve yazılım varlıklarının kayıtlarını takip etmek, bu kayıtların tutarlı olmasını sağlamak. Yazılım varlıklarının üretimi ve kullanıma alınmasının gerekli teknik ve yönetimsel onaylardan geçmesini sağlamak. Süreçlerde gereken iyileĢtirmeleri tespit etmek ve bunları uygulamak. Yerel yöneticiler SAM owner‟a karar verme aĢamasında yardımcı olacak bilgileri sağlamaktadırlar. SAM owner yerel yöneticilerden sürekli geribildirim alır. (ISO/IEC, 2006, p. 7) iii. Kurallar, süreç ve prosedürler Bu süreç ile hedeflenen, SAM'in planlanması, iĢlemesi ve kontrolünün sağlıklı bir Ģekilde sürdürülebilmesi için gerekli kuralların, süreçlerin ve prosedürlerin açık ve net bir Ģekilde belirlenmesidir. Kuralları, süreçleri ve prosedürleri yaratmak, gözden geçirmek, kabul etmek, düzenlemek ve kontrol etmek için yapısal bir yaklaĢım söz konusudur. Tüm kural, süreç ve prosedürlere (şu an yürürlükte olanlar ve eskiler) eriĢilebilir olmalı, hangi kural, süreç ve prosedürlerin hangi varlıklar için uygulanacağı bilinir olmalıdır. OluĢturulacak kural, süreç ve prosedürlerde kiĢilerin sorumlulukları belirtilmiĢ ve bunlar yasalarla çakıĢmıyor olmalıdır. Bu kural süreç ve prosedürlere karĢı gelinmesi halinde uygulanacak yaptırımlar belli olmalıdır. Kurallar en azından aĢağıdakileri içermelidir: Yazılım varlıkları ilgili Ģirket ilkeleri için bireysel ve departmanların sorumlulukları, Yazılım ve ilgili varlıkların bireysel kullanımları ile ilgili kısıtlamalar, Yasal düzenlemelere uygunluk kontrolü, (Örneğin, yazılımların lisanslanması.) Yazılım tedarik Ģartları, (Örneğin sadece tanınmıĢ tedarikçilerden satın alma gibi.) Yazılımların (para verilip alınması zorunlu değil) kullanımında ya da yüklenmesinde onay alınması gereksinimi, Bu kuralların ihlalinde uygulanacak disiplin yaptırımları.
yılda bir olmak üzere duyurulması gerekir. Duyurulunca çalıĢanlardan duyuruyu anladıklarına dair bir geri bildirim alınması gerekir. Bu prosedür ve kulların her zaman bir yerde asılı durması gerekir. Böylece personel, istediği zaman bakabilir. (ISO/IEC, 2006, p. 8) iv. Yetkinlik Bu süreç ile hedeflenen; SAM için gerekli yetkinlik ve deneyime sahip olunduğundan ve bu deneyimlerden yararlanıldığından emin olmaktır. Bu hedefin gerçekleĢtirimi bazı yapılması gereken aktiviteler vardır. Personelin (SAM ve lisanslamalar hakkında) aldığı eğitimlerin incelenmesi, üreticiler için yazılımın lisanslı olduğunun kanıtının ne demek olduğunun incelenmesi1, personele eğitim programları sunulması, yazılım lisans Ģartlarına uygunluk konusunda Ģirketlerden gelen direktiflerin incelenmesi gerekmektedir. (ISO/IEC, 2006, p. 9) b. Planlama ve gerçekleştirim süreçleri Planlama ve gerçekleĢtirim süreçlerinin hedefi, SAM'in etkin ve verimli bir Ģekilde tamamlanmasıdır. (ISO/IEC, 2006, p. 10) i. Planlama Etkin ve verimli bir Ģekilde sonuca ulaĢmak için hazırlık ve planlama yapılmalıdır. Bu hedef doğrultusunda; yönetim kurulunun onayına sunulmak üzere yönetim hedefleri geliĢtirilir ve planlanır. SAM'in gerçekleĢtirimi üzere, “SAM plan” adında bir plan oluĢturulur. Bu plan aĢağıdakileri özelliklere sahip olmalıdır: Hangi yazılım tiplerinin ve hangi yazılım varlıkların “SAM plan” kapsamına dahil edildiğinin belirtildiği açık ve net bir kapsam ifadesini 1 Bir firmaya yazılımının lisanslı olduğunu kanıtlayabilmek için sunulması gereken belgelere “lisanslı olduğunun kanıtı” denmiĢtir. (Örnek: seri numarası, hologram, fatura, kontrat vb.)
daha fazlası da üzerine eklenebilir. SAM planının gerçekleĢtirebilmesi için gerekli olan kaynakların (bütçe dahil) belirlenmesi gerekir. SAM‟in uygulanmasında baĢarılı mı olunuyor, yoksa gerileme mi olmuĢ diye çıkarım yapılabilecek çeĢitli performans ölçer metriklerin belirlenmesi gerekmektedir. (Örnek: varlıkların envanter kayıtları ile gerçek varlıkların tutarlılık %'si.) Otomasyonlar da dahil olmak üzere SAM‟in gerçekleĢtirilmesini desteklemek için yapılabilecek her türlü aktivite plana dahil olmalıdır. Bu plan yönetim kuruluna onaylatılmalı ve yılda bir güncellenmelidir. (ISO/IEC, 2006, p. 10) ii. Gerçekleştirim Bu süreçte, bir önceki süreçte çıkarılan SAM planını gerçekleĢtirilmesi hedeflenmektedir. Bu hedef doğrultusunda, SAM planını yıl boyunca etkileyebilecek değiĢiklikler, riskler ve sorunlar hakkında bilgi toplamak için çeĢitli mekanizmalar uygulamaya koymak gerekmektedir. Ayrıca; SAM owner tarafından düzenli aralıklarla, yönetim kuruluna sunulmak üzere SAM planının son durumu hakkında rapor hazırlanır. Ve SAM planı ile gerçekleĢtirimi arasında ortaya çıkan farklılıklar tespit edildiği anda dokümante edilir. (ISO/IEC, 2006, p. 11) iii. İzleme ve gözden geçirme Bu süreç ile hedeflenen, SAM‟in yönetim hedeflerinin baĢarılmıĢ olduğunun garanti edilmesidir. Bu hedef doğrultusunda; en az yılda bir kez olmak üzere resmi bir gözden geçirme iĢlemi yürütülür. Bu iĢlem dahilinde; SAM hedeflerinin ve SAM planının baĢarılı bir Ģekilde tamamlanıp tamamlanmadığına bakılır. SAM planında belirtilmiĢ olan performansla, gerçek performans karĢılaĢtırılır, oluĢmuĢ olabilecek problemlerin çözümlerine karar verilir. Kural, süreç ve prosedürler gözden geçirilir. En az yılda bir kere olmak üzere, yazılım ve yazılım varlıklarının mali açıdan en etkin biçimde düzenlenip düzenlenmediği gözden geçirilir.
alınan kararları dokümante edip bir kopyasını yönetim kuruluna sunar. (ISO/IEC, 2006, p. 11) iv. Sürekli iyileşme Bu süreç ile hedeflenen, hem kullanımdaki yazılım ve yazılım varlıklarında, hem de SAM'in kendisinde yapılabilecek iyileĢtirmelerin belirlenmesi ve gerçekleĢtirilmesidir. Bu hedef doğrultusunda; yıl boyunca, tüm kaynaklardan doğan iyileĢtirme fikirlerini toplayan ve kaydeden bir mekanizma olmalıdır. Gelen öneriler periyodik olarak incelenir, önceliklendirilir ve onaylanır. (ISO/IEC, 2006, p. 12) II. Ana SAM süreçleri SAM planının gerçekleĢmesi için yapılacak asıl iĢlerdir. Yazılım varlıklarının belirlenmesi, envanterlerin oluĢturulması, iliĢkilerin belirlenmesi ve buna benzer Ģeyleri bu kısım içermektedir. a. Envanter süreçleri Yazılım ve yazılım varlıkları için gerekecek depo ve kayıtları yaratıp muhafaza etmeyi ve diğer SAM süreçlerindeki yazılım ve yazılım varlıklarıyla bütünlük sağlamak için veri yönetme fonksiyonlarını geliĢtirmeyi amaçlar. (ISO/IEC, 2006, p. 12) i. Tanımlama Bu süreç ile hedeflenen, SAM kapsamında ele alınacak varlıkların belirlenmesi ve kolay yönetilebilmesi için ortak özelliklerine göre sınıflandırılmasıdır. Bu hedefin gerçekleĢtirimi için yönetilecek varlıklar ve yönetilecek varlıklarla beraber kaydedilecek bilgiler resmi olarak belirlenir. Bu varlıklar yaĢam döngüleri boyunca yönetilebilir ve izlenebilir olmalıdır. Yazılımlar gereksinime göre hem paket bazında, hem dosya bazında yönetilebilir olmalıdır. (file based / package based). (ISO/IEC, 2006, p. 13) Yönetilecek yazılım varlıkları neleri içerir?
Yazılımların dağıtım kopyaları, Yazılım sürümleri, Yüklü tüm yazılımlar, Yamalar, güncellemeler, Lisanslar, (alınanlar, çıkartılabilenler) Lisanların olduğuna dair kanıtlar, AnlaĢmalar (kullanım şartları dahil) hem elektronik ortamda, hem de varsa yazılı olanı, Yukarıda sayılanları tutacak elektronik ve fiziksel ortamlar, depolar, Lisanslama modelleri. (ISO/IEC, 2006, p. 13) Buradakiler olması zorunlu olanlardır. Bunlar haricinde varlıklar da yönetim kapsamına alınabilir. Çıkartılabilen lisans: Bir ürün için alınan lisansın baĢka Ģeylere de izin vermesi. (ISO/IEC, 2006, p. 4) (Örneğin, A ürünü, A2 ürününün alınmasında %50 indirim sağlıyor ve iki ürün de bedava veriyor gibi.) Depo: Kurulum CD'si, fatura gibi fiziksel ve ISO dosyası gibi elektronik medyaların tutulduğu güvenli bölge. Her yazılım varlığının hangi bilgileri olmalıdır? ID (Benzersiz tanımlama numarası) Ġsim ve tanım Konumu Sorumlu/Sahip Durumu (Test aĢamasında, kullanımda, geliĢtirme aĢamasında, vb.) Tipi (Yazılım, donanım, bina, kiĢi vb.) Sürüm (ISO/IEC, 2006, p. 13) ii. Envanter yönetimi Envanter: Kurulu/kurulu olmayan yazılım varlıklarının stoku, dökümü. Bu süreç ile hedeflenen; yaĢam döngüsü boyunca, yazılım varlıklarının fiziksel örneklerini uygun bir Ģekilde saklanması, tüm yazılım varlıkları ve yazılımsal/donanımsal birimler için gerekebilecek verilerin kaydedilmesidir.
sağlayacak prosedür ve kuralları oluĢturmak (izin ve yetki mekanizmaları dahil olmak üzere) ve yazılımların sürekli kullanılabilirliğini (Örnek: her yıl lisansların yenilenmesi) sağlamaktır. Böylece yazılımlara izinsiz yapılan eriĢim ve değiĢikliklerden zarar görmekten korunmuĢ olur. Yazılımların çalıĢabilecekleri tüm ortamlar, tüm yüklenmiĢ yazılımlar ve bu yüklenmiĢ yazılımların sürümleri, yüklü paketler ve lisans durumları bilinebilir olmalıdır. Yazılımların dağıtım kopyaları, yazılı ve elektronik kontratlar ile lisansların kanıtlarının envanterlerinin tutulması gerekmektedir. Envanterler lisans kullanımının sadece kurulan yazılım sayısına bakılarak belirlenemeyeceği durumlar için önemli bir hesap yapma kaynağıdır. (Örnek: Bir lisans iĢlemci sayısına göre, çalıĢan kiĢi sayısına göre veya bir sunucuya eriĢim yapabilen bilgisayar sayısına göre olabilir.) (ISO/IEC, 2006, p. 14) iii. Kontrol Bu süreç ile hedeflenen; yazılım varlıkları ile ilgili kontrol mekanizmaları geliĢtirilmesi, yazılım ve ilgili varlıklarda yapılan değiĢikliklerin kaydının tutulmasıdır. Bu hedef doğrultusunda yapılması gerekenler; yazılımlara ve yazılım varlıklarına yapılmıĢ durum, yer, yetkili/sahip, sürüm vs. değiĢikliklerinin tarihçesini tutan bir mekanizma kurulması, yazılımların tüm versiyonları ve imajlarının yönetimi, bakımı ve geliĢtirilmesi için kurallar ve prosedürler geliĢtirilip onaylanması, yazılımların kullanım ortamına alınmadan önce, gerekli testlerinin yapılmasını zorunlu kılacak prosedür ve kuralların geliĢtirilmesidir. (ISO/IEC, 2006, p. 15) b. Doğrulama ve uyum süreçleri SAM kuralları, süreçleri ve prosedürlerinde meydana gelmiĢ hataları yakalamayı ve yönetmeyi amaçlar. (ISO/IEC, 2006, p. 15) i. Kayıt doğrulaması
ve eksiksiz bir biçimde tutup tutmadığının denetlenmesi ve onay alınmadan değiĢiklik yapılmamıĢ olduğundan emin olunmasıdır. Bu hedef doğrultusunda; üç ayda bir, hangi platforma neyin kurulduğu ve aslında nelerin kurulabileceği karĢılaĢtırılır. Altı ayda bir, donanım envanterinin doğrulaması yapılır. (Donanımların konumu da doğrulanmalıdır.) Altı ayda bir, yazılım dağıtım kopyaları doğrulanır. Yıllık olarak lisans kanıtları kontrol edilir. Yıllık olarak lisanlardan çıkarılabilecek ek haklar incelenir. Ortaya çıkan uyumsuzluklar raporlanır. (ISO/IEC, 2006, p. 15) ii. Lisans uyumu Bu süreç ile hedeflenen, Ģirket tarafından kullanılan tüm yazılımların lisanslı olduğundan ve kullanım koĢullarına uygun kullanıldığından emin olunmasıdır. Bu hedef doğrultusunda yapılması gerekenler; her üç ayda bir sahip olunan lisanslar ile kullanımda olan lisansların uygunluğunun karĢılaĢtırılması, çıkabilecek uyumsuzlukların dokümante edilmesi, incelenerek asıl sebeplerin bulunması, çözümlerin önceliklendirilmesi ve uygulanmasıdır. (ISO/IEC, 2006, p. 16) iii. Güvenlik uyumu Bu süreç ile hedeflenen; yazılım ve ilgili varlıkların eriĢim ve kullanımlarıyla ilgili prosedürlere uyulup uyulmadığının kontrol edilmesidir. Bu hedef doğrultusunda yapılması gerekenler; kurallar ile pratikte uygulanan yöntemin aynı olup olmadığının yılda bir kontrol edilmesi, tespit edilen uyumsuzluklar raporlanmasıdır. Yapılan bu kontrol yazılım kullanma hakları, yükleme hakları ve dağıtım kopyalarına eriĢimi haklarını içermelidir. (ISO/IEC, 2006, p. 17) iv. Uyumluluk doğrulaması Bu süreç ile hedeflenen; Ģirket tarafından belirlenen politika ve prosedürlerle bu standardın uyumluluğunun kontrol edilmesidir.
akıĢlarının en az yılda bir bu standarda uyumluluk açısından denetlenmesi, bu denetlemenin yapıldığına dair belgelerin olması, olası bir uyumsuzluk halinde gerekli düzeltmelerin yapılmasıdır. (ISO/IEC, 2006, p. 17) c. Operasyon yönetim süreçleri ve arayüzleri SAM'in hedeflerine ulaĢmak için gereken temel operasyonları gerçekleĢtirebilmeyi amaçlar. (ISO/IEC, 2006, p. 17) i. İlişki ve kontrat yönetimi Bu süreç ile hedeflenen; diğer organizasyonlarla ve Ģirket içi bölümler arası iliĢkinin yönetilmesi, kaliteli ve kusursuz SAM servisleri tedarik edilmesi, yazılım, yazılım varlıkları ve servislerle alakalı kontratların yönetilmesidir. Bunları sağlayabilmek için yazılım sağlayıcılarla görüĢmeleri ve iliĢkileri düzenleyecek kural ve iĢ akıĢları geliĢtirilmelidir. Yazılım sağlayıcılar her altı ayda bir değerlendirilmeli e performansın beğenilmemesi durumunda bu dokümante edilerek, gerekli çözümler uygulanmalıdır. MüĢteriler ile bağlantıları düzenleyecek kural ve iĢ akıĢları geliĢtirilmelidir. MüĢteriler IT dıĢındaki departmanlar olabilir. Sadece dıĢ müĢteri olmak zorunda değildirler. MüĢteri tarafı yönetiminde kimin kiminle ilgileneceği ve bu kiĢilerin sorumluluklarının belli olması gerekmektedir. En az yılda bir kez olmak üzere, Ģirketin ve müĢterilerin Ģu anda ve ileride nasıl yazılımlara ihtiyaç duydukları ve duyacakları belirlenmelidir. MüĢteri memnuniyeti bilgilerinin en az yılda bir derlenip raporlanması ve beklenenin altında olması durumunda gerekli düzeltmelere gidilmesi gerekmektedir. Kontrat yönetimi ile ilgili olarak, kontratların imzalanır imzalanmaz sisteme iĢlenmesi, kontratların düzenli ve yedekli bir Ģekilde güvenli olarak saklanması, altı ayda bir ve kontrat bitimlerinden hemen önce dokümante edilmiĢ belgelerin okunması, incelenmesi ve ne yapılacağına (yenilemek, bırakmak) karar verilmesi gerekmektedir. Kontrat yönetimi için gerekli prosedür ve kurallar belirli olmalıdır. (ISO/IEC, 2006, p. 18) ii. Finansal yönetim
çıkarmak, muhasebe yapmak; böylece vergiler, finansal raporlar ve çeĢitli hesaplamalar için gereken finansal bilgilerin hazır durumda olmasını sağlamaktır. Bu hedef doğrultusunda yapılacaklar; yazılım varlıklarıyla alakalı olabilecek finansal bilgilerin belirlenmesi, taraflar arasında mutabakat sağlanması, bunların dokümante edilmesi; yazılım, ilgili varlıklar ve bakım vs. masrafları için gerekli bütçenin resmi olarak ayrılması, yapılan harcamaların muhasebesinin yapılması, fiyat geçmiĢleri de dahil olmak üzere tüm finansal bilgilerin tüm varlıklar için tek tek tutulması, yapılan harcamaların planlanan bütçeyle en az üç ayda karĢılaĢtırılmasıdır. KarĢılaĢtırma sonucunda harcamalar planlanandan daha vasat durumda ise bu durum dokümante edilerek ve yapılacağına karar verilmelidir. (ISO/IEC, 2006, p. 19) iii. Servis düzeyinde yönetim Bu süreç ile hedeflenen SAM ile iliĢkili servis seviyelerinin tanımlanması, kaydedilmesi ve yönetilmesidir. Yazılım alımı, kurulumu, taĢınması ve değiĢiklikleri ile ilgili servis düzeylerinin belirlenmiĢ ve tarafların anlamıĢ olması gerekir. Servis seviyeleri ile ilgili müĢteri ve çalıĢan sorumluluklarının belirlenmiĢ olması gerekir. En az üç ayda bir, servis düzeyindeki ile gerçek iĢ yükü arasındaki fark raporlanır. En az üç ayda bir ilgili birimlerden performans değerlendirmesi yapmaları istenir. Eğer servis düzeyleri karĢılanamıyorsa, iĢ yükü daha fazlaysa, o zaman bu uyumsuzluk nedenleri ile birlikte dokümante edilmelidir. Taraflardan gelen performans/beğeni raporları incelenir ve yapılacaklara karar verilir ve dokümante edilir. (ISO/IEC, 2006, p. 19) Servis düzeyinde yönetim anlaĢmaları (SLA) hakkında daha fazla bilgi için bkz. Service level management s. 11 iv. Güvenlik yönetimi Bu sürecin hedefi tüm SAM aktivitelerindeki bilgi güvenliğini etkili bir biçimde sağlamaktır.
yazılım ve varlıklara eriĢim belirli kurallara bağlı olması, bu kuralların uygulanmasını zorunlu kılacak eriĢim kısıtlamaların uygulanması, bu güvenlik uygulamaların pratikte de uygulandığına dair kanıtların ve belgelerin olması gerekmektedir. (ISO/IEC, 2006, p. 20) III. SAM için birincil süreç arayüzleri SAM kapsamındaki yazılımların satın alınması/geliĢtirilmesinden, Ģirketin yazılımı kullanmayı bırakmasına kadar olan yaĢam döngüsüne dair SAM süreçlerini bu kısım içermektedir. a. Yaşam döngüsü süreç arayüzleri ISO/IEC 19770-1'in bu bölümü bu yaĢam döngüsü süreçleri için SAM gereksinimlerini belirtmektir. ISO/IEC 12207 ve ISO/IEC 20000'in temel yaĢam döngüsü süreçleriyle bağlantılıdır. (ISO/IEC, 2006, p. 20) i. Değişiklik yönetim süreci Bu sürecin hedefi SAM sürecine etkisi olan tüm olayların kayıt altına alınması gereksinimin karĢılanmasıdır. Bu hedef doğrultusunda; tüm yazılımları, ilgili varlıkları ve SAM‟i etkileyecek değiĢiklik istekleri belirlenmeli ve kayıt altına alınmalıdır. Bu değiĢiklikler gerçekleĢtirilmeden önce, olabilecek yan etkiler araĢtırılmalıdır. DeğiĢiklik istekleri ve yapılan değiĢiklikler kayıt altına alınmalıdır. Böylece sorumlular her zaman bilinir olacaktır. Yapılacak değiĢiklikler önceliklendirilmeli ve ilgili yetkililer tarafından onaylanmalıdır. DeğiĢikliklerin baĢarılı olup olmadığı dokümante edilmeli ve periyodik olarak incelenmelidir. (ISO/IEC, 2006, p. 21) ii. Satın alma süreci Bu süreç ile hedeflenen yazılım kontrollü bir biçimde satın alınması ve uygun bir Ģekilde sisteme kaydedilmesidir.
belli olmalıdır. Alınacak ürünün sipariĢi ile ilgili prosedürlerin belli olması gerekmektedir. Bu prosedürler aĢağıdakileri içermelidir ancak bunlarla sınırlı değildir: Gereksinimlerin belirlenmesi, Gerekli teknik ve yönetimsel onayın alınması, Mümkünse hazırda var olan lisansların tekrar kullanılması. Ayrıca teslim alma ile ilgili prosedürlerin belirli olması gerekmektedir. Bu prosedürler aĢağıdakileri içermelidir ancak bunlarla sınırlı değildir: Ürünlerin eksiksiz alınması, Lisans kanıtlarının ve faturanın alınması, Alınan ürünün kontrol edilmesi ve güvenli bir Ģekilde saklanması. (ISO/IEC, 2006, p. 21) iii. Yazılım geliştirme süreci Bu sürecin hedefi yazılımların ve ilgili yazılım varlıklarının geliĢtirilmesinin SAM‟in Ģartlarına uygun bir Ģekilde yapılmasıdır. Bu hedef doğrultusunda; yazılımın kullanılacağı mimari ve konfigürasyonlar ile yazılımın sahip olabileceği lisansla ilgili ve diğer bağımlılıklar biliniyor olmalıdır. (ISO/IEC, 2006, p. 22) iv. Yazılımı yayına sunma süreci Bu sürecin hedefi yazılım ve yazılım varlıklarının yayına sunulmasının SAM'in Ģartlarına uygun bir Ģekilde yapılmasıdır. DerlenmiĢ yazılımın önceden belirli bir test ortamında kabul testine tabi tutulması gerekmektedir. Release sıklığı ve release tipleri önceden belirlenmiĢ ve üzerinde anlaĢılmıĢ olmalıdır. Yani, yazılımın yayına sunulması ile ilgili iĢ akıĢı belli olmalıdır. BelirlenmiĢ release sıklığı ile ürünün çıkarılma sıklığının birbiriyle tutup tutmadığı ve değiĢim isteklerinin (yaĢanılan problemle beraber) kaydedilip vaka yönetimine bildirilmesi gerekmektedir.
2006, p. 22) v. Yazılım çalışma ortamına dağıtma süreci Bu sürecin hedefi; yazılımın ve ilgili yazılım varlıklarının çalıĢma ortamına dağıtılması ve daha sonra çalıĢma ortamında gerekli düzenlemelerin gerçekleĢtirilmesinin SAM'in Ģartlarına uygun bir Ģekilde yapılmasıdır. Bu hedefin gerçekleĢtirimi için yapılması gereken çeĢitli aktiviteler bulunmaktadır. Sorumlular tarafından, yazılımın ve yazılım varlıklarının çalıĢma ortamına dağıtımının onaylanması gerekir. Yazılımın dağıtımının baĢarılı olmaması durumunda uygulanacak önlem ve tedbirler belli olmalıdır. Yazılımın sadece ilgili kiĢilere dağıtımı sağlanmalıdır. Yazılım ve varlıklarla ilgili yapılmıĢ tüm değiĢikliklerin kaydedilmesi gerekir. Kurulumdan sonra istenilen ile kurulanın aynı olup olmadığının kontrol edilmesi gerekir. Yazılımın çalıĢma ortamına dağıtılmasının baĢarılı ya da baĢarısız olması kayıt altına alınır ve periyodik olarak gözden geçirilir. (ISO/IEC, 2006, p. 23) vi. Arıza yönetim süreci Bu sürecin hedefi; yazılım ve yazılım varlıklarıyla iliĢkili operasyonlarda meydana gelen arızaların izlemesi ve çözülmesidir. Bu hedef doğrultusunda; yazılımları, yazılım varlıklarını ya da SAM süreçlerini etkileyen arızalar kayıt altına alınır ve çözüm için önceliklerine göre gruplandırılır. Bu arızalar önceliklerine göre çözülür ve çözüm dokümante edilir. Bunları gerçekleĢtirecek kural ve prosedürlerin geliĢtirilmesi, onaylanması ve yayına alınması gerekir. (ISO/IEC, 2006, p. 24) Arıza yönetimi ITIL‟da Incident Management baĢlığı altında ayrıca incelenmiĢtir. Daha fazla bilgi için bkz. Incident management s. 23 vii. Problem yönetim süreci Bu süreç ile hedeflenen yazılım ve yazılım varlıklarının çalıĢır halde olmasının sağlanmasıdır. Bu da Arıza Yönetimi sürecinde raporlanmıĢ arızaların incelenip kök problemlerin bulunması ile sağlanır.
SAM süreçlerini etkileyen arızalar kayıt altına alınır ve etkilerine göre sınıflandırılır. Yüksek öncelikli ve sık tekrar eden arızaların altında yatan nedenler analiz edilir ve çözüm için önceliklendirilir. Arızaların altında yatan nedenler tespit edildikten sonra dokümante edilir ve arıza yönetimine bildirilir. Problemler, önceliklerine göre çözülür ve çözümler dokümante edilir ve arıza yönetimine bildirilir. (ISO/IEC, 2006, p. 24) Problem yönetimi ITIL‟da Problem Management baĢlığı altında ayrıca incelenmiĢtir. Daha fazla bilgi için bkz. Problem management s.24 viii. Kullanımdan kaldırma süreci Bu süreç ile hedeflenen; yazılım ve ilgili varlıkların kayıt altında ve Ģirket kurallarına uygun olarak kullanımdan kaldırılmasıdır. Bu hedef doğrultusunda; yazılım ve donanımların güvenli olarak kullanımdan kaldırılmalarını sağlayacak kural ve prosedürlerin oluĢturulması, onaylanması ve yayına alınması gerekir. Bunun için de; donanım kaldırılmadan önce içindeki yazılımlar silinir. Yeniden kullanılabilecek lisanslar belirlenir, tekrar kullanılamayacak varlıklar uygun bir Ģekilde yok edilir. Kaldırma iĢlemine engel olan kontratlar veya benzer çalıĢmalar varsa bunlar tespit edilerek öncelikle bu sorunların çözülmesi sağlanır. (ISO/IEC, 2006, p. 24) ISO/IEC 19770-2: Software Identification Tag ISO/IEC 19770-2, her bir yazılım varlığının ayrı ayrı etiketlenebilmesi için gerekli olan “software identification tag” standardını tanımlar. Etiketler, tüm varlıkları birbirinden ayırmanın yanı sıra, yazılım varlığı hakkında (sürümü, bağımlı olduğu yazılımlar, üretici vs.) bilgiler de sunabilir. Software identification tag; yazılım ürünü hakkında, o ürünü yönetmeyle ilgili bilgileri ve o ürün üzerindeki yetki tanımlarını içeren XML dokümanıdır. Computing device adı verilen aygıtlara, yazılım ile birlikte yüklenir. Computing device; önemli iĢlemleri gerçekleĢtiren fonksiyonel ünitedir, insan müdahalesi olmadan çeĢitli aritmetik ve mantıksal iĢlemleri yerine getirirler.
Asset Management süreçlerini desteklemek amacıyla geliĢtirilmiĢtir. Ayrıca, yazılım yetki etiketleri için uluslararası bir standart elde etme amacıyla geliĢtirilen 19770- 3 kısmıyla da ortak çalıĢması planlanmaktadır. (ISO/IEC, 2009, p. vi) Software identification taglerin avantajları Software identification tagler, yazılımın geliĢtirme, lisanslama, dağıtım, kurulum ve daha sonraki yönetim aĢamalarında rol alan paydaĢları için bir çok avantaj sağlamaktadır. Software identification taglerin bazı avantajları; Belirli bir amaç (örneğin; lisanslama, iyileştirme, paketleme ya da çeşitli bağımlılıklar belirleme gibi) doğrultusunda yönetilecek yazılım ürünlerini tutarlı bir biçimde ve çeĢitli yetkiler dahilinde tanımlama yeteneği getirir. Software identification tagler, geleneksel tekniklerinden farklı olarak daha kesin tanımlamalar sağlayan meta- data ‟ya sahiptirler. Hem software identification tag bilgilerini kullanarak, hem de SO/IEC 19770-3‟te bulunacak olan software entitlement tag bilgilerini kullanarak lisans uyumu konusunda otomatikleĢtirilmiĢ yaklaĢımlar kullanılabilmesini sağlar. Belirli bir yazılım paketinin aktif olarak kullanılıp kullanılmadığını belirlemek için bilgiler sağlar. Paket seviyesindeki yönetimle dosya seviyesindeki yönetimi birbirine bağlamak amacıyla paketlerin yapısal özellikleri (örneğin; o paketle ilgili sistem ayaları ya da bazı bileşenlerin-örneğin dosyalar- listeleri) hakkında kapsamlı olarak bilgi sağlar. Silinebilir ya da paylaĢılan depolama birimlerine kurulmuĢ, ya da sanal platformlarda bulunan yazılımların karmaĢıklığı konusunda yardımcı olur. (platformların zaman içinde gelişen yetenekleri ve platform ve aygıtları yükleyenler konusunda) Software identification tag içindeki farklı paydaĢların (yazılım geliştiriciler, yazılımı lisanslayanlar, yazılımı paketleyenler, yazılımı kullanıcılara dağıtanlar, yazılımı kurmakla ve yazılımı kullanım aşamasında yönetmekle sorumlular) tanımlarını ve gereksinimlerini yansıtır. (ISO/IEC, 2009, p. vi)
kurulacağı ya da çalıĢtırılacağı bilgisayar, donanım aygıtı, sanal ortam gibi birimleri üreten organizasyonlardır. ISO/EC 19770‟in bu bölümüne göre platform sağlayıcılar, platform ya da iĢletim sistemi seviyesinde etiket yönetim yetenekleri sağlamak zorundadırlar. (ISO/IEC, 2009, p. 1) Örneğin, Windows Vista software identification tag deposunu yönetmek için dört adet API sunmaktadır. bkz. Ek 9: Software Identification Tag Yönetimi İçin Windows Vista API‟leri s. 112 2. Yazılım sağlayıcılar Kurulum ya da dağıtım için, yazılım geliĢtiren (“software creators” (ISO/IEC, 2009, pp. 9 - 4.1.28)), yazılımı paketleyen (“software packagers” (ISO/IEC, 2009, pp. 10 - 4.1.36)) ya da yazılımı lisanslayan (“software licensors” (ISO/IEC, 2009, pp. 10 - 4.1.33)) varlıklardır. Yazılım üreticilerini (“software manufacturer” (ISO/IEC, 2009, pp. 10 - 4.1.34)) , bağımsız yazılım geliĢtiricilerini (“software developer” (ISO/IEC, 2009, pp. 10 - 4.1.29)), danıĢmanları ve daha önceden üretilmiĢ yazılımları yeniden paketleyenleri içerir. Ayrıca Ģirket içindeki yazılım geliĢtiriciler de olabilirler. (ISO/IEC, 2009, p. 1) Yazılım sağlayıcılar, yazılımlarını etiketleyerek sunabilir veya bu iĢi üçüncü parti etiket sağlayıcılara devredebilirler. 3. Etiket (tag) sağlayıcılar Yazılım tanımlama etiketlerini (“software identification tags” (ISO/IEC, 2009, pp. 10 - 4.1.31) ) yaratan (“tag creators” (ISO/IEC, 2009, pp. 11 - 4.1.39)) ya da yeniden düzenleyen (“tag modifiers” (ISO/IEC, 2009, pp. 11 - 4.1.40)) varlıklardır. Etiket sağlayıcılar, yazılım geliĢtiren organizasyonun bir parçası olabilirler ya da üçüncü parti organizasyonlar olabilecekleri gibi yazılım tüketicileri de olabilirler. (ISO/IEC, 2009, p. 1) Örneğin TÜPRAġ‟ın ISO/IEC 19770-2 standardını kullanması halinde daha önce etiketlenmemiĢ yazılımlar için kendi iç bünyesinde etiket sağlaması gerekmektedir.
yaratan, yeniden düzenleyen ya da kullanan araçlar geliĢtiren varlıklardır. Bu araçlar, software identification tagleri otomatik olarak üreten geliĢtirme ortamları sunarlar. Bunlar, tagleri kurulum süreci dahilinde yaratırlar ya da yeniden düzenlerler. Ayrıca; yazılımın yaĢam döngüsü boyunca, sahip olduğu tagleri düzenleyen ya da bu taglere sahip olmayan yazılımlara tag ekleyen masaüstü uygulamalarını içerirler. (ISO/IEC, 2009, p. 1) 5. Yazılım tüketicileri Yazılımı satın alan, kurulumunu yapan ve yazılımı kullanan varlıklardır. ISO/IEC 19770‟in ikinci kısmında belirtilen software identification tagler tarafından sağlanan bilgilerden faydalanmayı amaçlarlar. (ISO/IEC, 2009, p. 1) Software identification tagin kullanılabileceği platformlar ISO/IEC 19770-2‟de platform diye belirtilen kavram, yazılımın kurulup çalıĢtırılacağı bilgisayar, donanım veya çeĢitli sanal ortamları temsil etmektedir. (ISO/IEC, 2009, pp. 8 - 4.1.17) 1. Temel platformlar Platformlar içerdikleri configuration item‟ların (ISO/IEC, 2009, pp. 7 - 4.1.5) sahip olduğu software identification taglerin detaylarından bağımsız bir Ģekilde var olmalıdır. Software identification tagleri etkin olarak elde etmek ve saklamak için süreçler tanımlamalıdır. (ISO/IEC, 2009, p. 25) Platformlar, software identification tagleri, iĢletim sistemlerinin dosyaları iĢlemesine benzer bir süreç dahilinde saklamalıdır. Software identification taglerde oluĢan bir hata, kolaylıkla keĢfedilebilsin diye merkezi bir konumda tutulmalıdır. (ISO/IEC, 2009, p. 25) ISO/IEC 19770‟in bu bölümündeki gereklilikleri yerine getiren bir platform aĢağıdakileri içermelidir: Temel ekleme, düzenleme, okuma ve silme iĢlemleri, Denetim yetenekleri; o Belirli bir configuration item‟ın kimin tarafından ve ne zaman yüklediğinin belirlenebilmesi,
zaman düzenlendiğinin belirlenebilmesi, o Belirli bir configuration item‟ın kimin tarafından ve ne zaman silindiğinin belirlenebilmesi. Güvenlik; o Software identification tagleri kimin yaratıp düzenleyebileceğini belirleyebilme, o Software identification tagleri kimin okuyabileceğini belirleyebilme. (ISO/IEC, 2009, p. 25) 2. Sanal ortamlar Sanal ortamlar, computing device denilen aygıtlara yüklenirler ve keĢfetme araçlarına (discovery tools) kendilerini tanıtmak için kendilerine özel software identification tagler sağlarlar. Computing device; önemli iĢlemleri gerçekleĢtiren fonksiyonel ünitedir, insan müdahalesi olmadan çeĢitli aritmetik ve mantıksal iĢlemleri yerine getirir. (ISO/IEC, 2009, pp. 7 - 4.1.4) Örneğin bir computing device‟a Java Virtual Machine (JVM) yüklendiğinde, software identification tag ile birlikte yüklenir. (ISO/IEC, 2009, p. 25) 3. Sanal makineler Sanal makineler, host olan iĢletim sisteminden farklı olarak guest bir iĢletim ortamı sunarlar. Sanal makinelerde de software identification tagler bulunmalıdır. KeĢfetme sürecinin bir parçası olarak, keĢfetme araçları (discovery tools) sistem hakkında bilgi toplamalıdır. Eğer sistem bir sanal makine ise, sanal makinenin detayları olarak, sanal makinenin host ortamı gibi bilgiler de toplanmalıdır. (ISO/IEC, 2009, p. 26) KeĢfetme araçlarının sanal makineler hakkında bilgi toplaması yeterli olup, sanal ortamın içerisine yüklü yazılımları keĢfetmek ve yönetmek sorumluluk kapsamı dıĢındadır. Sanal ortam kendi içerisinde ayrıca yönetilmelidir.
Böyle durumlarda software identification tag, belirli computing device‟a yüklenmiĢ yazılımı tanımlamak ve tag bilgisi üretmek durumundadır. Bu da computing device‟ın ortak sistem konumuna software identification tag sağlamakla gerçekleĢir. Yazılım paketini yüklemek için, software identification tagin ikinci kopyası da dizinin en üst seviyesine eklenir. Araç sağlayıcılarının, bir computing device üzerinde birden fazla software identification tag bulunabileceğinin farkında olması gerekir. Ayrıca computing device‟ın bir yazılım paketi için sadece bir kurulum içerebileceğinin de farkında olmaları gerekir. (ISO/IEC, 2009, p. 26) Software identification tag yaşam döngüsü Software identification tag yaĢam döngüsünde hiyerarĢik bir düzen söz konusudur. Yazılım yaratıcısından yazılımı tüketen firmalara kadar iĢleyen yaĢam döngüsünün yer aldığı diyagram için bkz. Ek 6: Software Identification Tag Yaşam Döngüsü s. 109 En baĢta software identification tag creation gerçekleĢtirilir. Software tag creation dahilinde en azından zorunlu elemanları içeren software identification taglerin yaratılması gerekmektedir. Daha sonra SAM‟e ve tanımlama iĢlevlerine yardımcı olması açısında isteğe bağlı olarak baĢka bir takım tanımlama elemanları da geliĢtirilir. Ardından software identification tag modification gerçekleĢtirilir. Software identification tag modification dahilinde ek software identification tag verileri sağlanır. (Örneğin, release management için ilgili tanımlama elemanları yaratılması.) Software identification tag verilerinin tutarlı olması gerekmektedir. Software identification tag use aĢamasında, organizasyonun sisteminde yüklü olan tüm software identification tagler bulunur ve raporlanır. Software identification tagler, yetkilerle eĢleĢmesi için kullanılır. Bu software identification tag bilgileri kullanılarak SAM prosedürleri uygulamaya konur. Software identification tag correction aĢamasında ise, software identification tagleri bulunmayan yazılımlar için software identification tagler
ve bozuk olan software identification tagler düzeltilebilir. (ISO/IEC, 2009, p. 22) 1. Software identification tag creation Tag yaratıcıları genellikle yazılım yaratıcılarıyla aynı olmaktadır. Yazılım geliĢtirilirken yazılım geliĢtiriciler, yazılım paketlerini tanımlamak için ilgili software identification tagleri de yaratırlar. Software identification tag creatorlar aĢağıdaki rollerde olabilirler: Software manufacturer: Software manufacturer, belirli bir software configuration itemı yaratırken aynı zamanda software identification tagi de yaratabilir. Yazılımın kurulum aĢamasında software identification tag sisteme iĢlenir. Software publisher: Eğer yazılım bir Ģirket tarafından yaratılıyor ve baĢka bir Ģirket tarafından yayınlanıyorsa, yazılımı yayınlayan Ģirket, packaging aĢamasında yazılımın kurulum aĢamasının bir parçası olarak software identification tagleri yaratabilir. Distributor, packager, value-added reseller ve diğer tag modifier organizasyonlar: Yazılımın dağıtımını yapan Ģirketler yazılım tüketicilerinin ihtiyaçlarını karĢılayan standartlaĢmıĢ software identification tagleri yaratmazlar. Eğer bir yazılımın software identification tagi yoksa, SAM practitioner rolünü üstlenmiĢ kiĢi, yazılıma tag yaratma görevini gerçekleĢtirir. (ISO/IEC, 2009, p. 23) 2. Software identification tag modification Software identification tagleri düzenleyen ya da software identification taglere yardımcı bilgiler ekleyen veya her ikisini birden yapan Ģirket ya da kiĢiler tag modifier sayılırlar. Software identification tag modifierlar aĢağıdaki rollerde olabilirler: Distributor Reseller Value-added reseller Republisher Packager Discovery tool sağlayıcıları Deployment tool sağlayıcıları
identification tag use Yazılım tüketicileri standartlaĢmıĢ software identification tag verilerinin nihai yararlananları olsa da, discovery toolları ve iĢletim sistemleri bu verileri kullanan temel sistemlerdir. Software identification tagleri okurlar ve verilmiĢ configuration item kümesi hakkında bilgi toplarlar. Software identification tag userlar aĢağıdaki rollerde olabilirler: SAM owner IT destek uzmanları Software configuration item sahipleri (ISO/IEC, 2009, p. 24) 4. Software identification tag correction Software identification taglerin diğer bileĢenlerle beraber yönetilmesi gerekse de, bir tagin silinmesi, kaldırılması, bozulması gibi durumlar oluĢabilir. Software identification taglerin güncel ve doğru olup olmadığını onaylamak için birkaç metot seçilebilir. Bu metotlar, discovery toollar tarafından toplanmıĢ verilerin yüksek seviyeli entegrasyonunu sağlamaktadırlar. Hangi durumda olursa olsun, verinin tutarlılığını sağlamak amacıyla discovery agentlara uygun metotlar bulunmaktadır. Uygun bir algoritma kullanılarak, bir SAM discovery toolu, sistemin gerekli software identification taglere sahip olup olmadığını ve bunlara ek olarak gerekli dosyalara sahip olup olmadığını kısa sürede onaylayabilir. (ISO/IEC, 2009, p. 24) .swidtag Unique registration ID (regid) Software identification tagler birçok farklı organizasyon tarafından yaratılabilir ve merkezi bir kayıt yetkilendirmesinin var olması zorunlu değildir. Merkezi bir yetkilendirme olmaması, tagin kim tarafından yaratıldığının tüm dünya çapında benzersiz bir kimlik numarası ile belirlenmesini zorunlu kılmaktadır. Bunu sağlamak için regid kullanır. Regid, benzersiz isimlendirme yetkisi sağlar. (ISO/IEC, 2009, p. 15)
da bir Ģirket tarafından yaratılabilir. Domain isminin aktif olması gerekmemektedir. Sadece belirli bir süre için alınmıĢ olması yeterlidir. Regid ismi aĢağıdakileri içerir: “regid” kelimesi – Unique registration ID “regid” ile baĢlamalıdır. Bir nokta “.” YYYY-AA formatında bir tarih – bu tarih, Ģirketin domaini aldığı tarih olmalıdır. Bir nokta “.” Software identification tagi yaratan Ģirket ya da kiĢinin domain isminin tersten yazılıĢı. Ġsteğe bağlı olarak, kendi isimlendirme yetkisine sahip olan alt- varlıkları tanımlamak için bir string daha eklenir. Bunu eklerken; o Bir virgül “,” o Domain isminin sahibi, virgülden sonrasına istediği uzunlukta bir metin girebilir. Domain ismi olarak example.com ya da example.net‟e sahip olan bir Ģirketin örnek regidleri için bkz. Ek 7: „regid‟ Değerlerinin Örnekleri s. 110 .swidtag dosyası standardı Software identification tag XML veri yapısında tanımlanır. Bu standardın XSD Ģeması ISO‟nun sitesinde halka açık bir Ģekilde tanımlıdır: http://standards.iso.org/iso/19770/-2/2009/schema.xsd Software identification tag dosyaları .swidtag dosya uzantısına sahip olmalıdırlar ki keĢfetme araçları tarafından tanınabilsinler. Her platform sağlayıcısı, software identification taglerin nerede saklanacağını belirtmelidir. Farklı platformlar için örnek tag konumları için; bkz. Ek 8: Farklı Platformlar İçin Tag Konumu Örnekleri s. 111 Benzersiz tanımlayıcılar Her etiketin benzersiz bir kimlik numarası olmalıdır. Tekil tanımlamaları gerçekleĢtirmek için software_id denilen bir birincil kimlik kullanılır. Bu kimlik iki parçadan oluĢur: tag_creator_regid
bir referans da olabilir. GUID hakkında daha fazla bilgi için bkz. Globally unique identifier (GUID) s.73 .swidtag’ın içermesi gereken zorunlu ögeler (mandatory elements) Bu kısımda tanıtılan elemanlar, standarda uygunluk için kullanılması gereken zorunlu elemanlardır. Bunların eklenmemesi, ISO/IEC 19770-2 standardına uyulmaması anlamına gelir. 1. ‘entitlement_required_indicator’ Boolean bir değerdir. Lisans yenileme gibi durumlarda incelenip izin alınma süreçlerine katılmasının zorunlu olup olmadığını belirtir. Lisanslı yazılımlarda lisans yenilemeleri maliyet olduğundan, veya yasal zorunluluklardan dolayı zamanla gözden geçirmeler yapmak gerekebilir. Ancak açık kaynak veya ücretsiz yazılımların izne tabi olması gerekmeyebilir. Bu öge ile hangi yazılımların izne tabi olduğu belirtilir. (ISO/IEC, 2009, p. 28) 2. ‘product_title’ Yazılımın yaratıcısı tarafından, yazılıma verilmiĢ olan isim. Bu değer, son kullanıcı tarafından ya da raporlara odaklanmıĢ olan computing device tarafından kullanılır. SAM sürecinin bir parçası olarak genellikle kullanılmaz. (ISO/IEC, 2009, p. 28) 3. ‘product_version’ Ürünün versiyon bilgisinin temsilini sağlamaktadır. (ISO/IEC, 2009, p. 29) 4. ‘software_creator’ Yazılım paketini üreten yazılım üreticisinin kim olduğunun tanımlanmasını sağlar. Yazılım yaratıcılarının, farklı ülkelerden olsalar bile isimleri tamamen aynı
Benzersizliği sağlamak için bu elemanın yazılım yaratıcısı için regid içermesi gerekmektedir. (ISO/IEC, 2009, p. 30) 5. ‘software_licensor’ Etiketin temsil ettiği yazılım paketinin telif haklarının sahibinin ifade edilmesini sağlar. Yazılım lisans sahiplerinin, farklı ülkelerden olsalar bile isimleri tamamen aynı olabilir. Ancak bunlar tamamen farklı varlıkları temsil ediyor olabilirler. Benzersizliği sağlamak için bu elemanın yazılım lisans sahibi için regid içermesi gerekmektedir. (ISO/IEC, 2009, p. 30) 6. ‘software_id’ Belirli bir ürünün belirli bir versiyonuna referans olarak kullanılabilecek bir bilgi sağlar. Her yazılımın her sürümü için ayrı bir unique_id ‟nin olması gerekmektedir. (ISO/IEC, 2009, p. 31) 7. ‘tag_creator’ Etiketi hangi etiket yaratıcısının yarattığının ifade edilmesini sağlar. Tag yaratıcılarının, farklı ülkelerden olsalar bile isimleri tamamen aynı olabilir. Ancak bunlar tamamen farklı varlıkları temsil ediyor olabilirler. Benzersizliği sağlamak için bu elemanın tag yaratıcısı için regid içermesi gerekmektedir. (ISO/IEC, 2009, p. 32) .swidtag’ın içerebileceği diğer ögeler (optional elements) Bu kısımda tanıtılan elemanlar, standarda uygunluk için kullanılması gereken zorunlu olmayan, ancak ekstra bilgi sağlamak için kullanılabilecek elemanlardır. 1. ‘abstract’ Tagin temsil etti yazılım paketinin ne iĢe yaradığı hakkında bilgi veren bir özettir. Çoklu dil desteği de bulunmaktadır. (ISO/IEC, 2009, p. 33) 2. ‘component_of’
(baba-çocuk ilişkisinde, baba, çocuğun ait olduğu yazılım paketi anlamına gelmektedir.) Bu eleman genellikle, fazladan bileĢen yüklendiğinde ve bu bileĢenlerin önceden var olan paketlerle iliĢkisi olduğu durumlarda kullanılır. Bu eleman, var olan pakete ek bir özellik katan bir paket yüklendiğinde kullanılır. (ISO/IEC, 2009, p. 33) 3. ‘complex_of’ Bu eleman, bir paket için çocuk iliĢkilerini tanımlar. (çocuk ilişkisinde çocuk, o pakete ait olan paketleri gösterir.) Bu eleman, bir takıma ait olan ürünlerin listesini göstermek amacıyla kullanılır. Bu eleman, bir takıma ait olan ürünlerin benzersiz tanımlayıcılarının listesinden oluĢur. (ISO/IEC, 2009, p. 34) 4. ‘data_source’ Son kurulumun veri kaynağının temelidir. CD, MSDN gibi değerleri içerebilir. Bu eleman ile configuration item‟ların nasıl yüklendiğinin bilgisinin kolaylıkla belirlenebilmesi mümkün olur. (ISO/IEC, 2009, p. 35) 5. ‘dependency’ Bu elaman, bir yazılımın çalıĢması için baĢka bir ürüne ihtiyacının olup olmadığının belirlenmesi için vardır. Yazılım lisansları ya da yazılım yetki gereksinimleri için kullanılmamalıdır. (ISO/IEC, 2009, p. 35) 6. ‘elements_owner’ Bu eleman, tag verilerinde kimin hakka sahip olduğunun belirtilmesini sağlar. Bir elemanın bir sahibinin olduğunun belirtilmesi, elemanın sahibinin izni olduğu durumda, o elemanda bir değiĢiklik yapılabileceği, diğer türlü o elemanda herhangi bir değiĢiklik yapılamayacağı anlamına gelir. (ISO/IEC, 2009, p. 36) 7. ‘installation_details’ Belirli bir yazılım paketi kurulumunda, software identification taglerin yerinin tam yerinin bilgisini tutan elemandır. Her yazılım kurulumu için, sisteme eklenen iki adet tag vardır. Bunlardan birisi kök dizine konur, öteki ise ortak dizine konur. (ISO/IEC, 2009, p. 37)
düzenleyicisi tarafından software identification tage belirli anahtar kelimeler eklenebilir. Böylelikle software identification taglerin belirli bir konu doğrultusunda arama motorları tarafından bulunması konusunda, tag yaratıcılarına ya da tag düzenleyicilerine yardımcı olunur. (ISO/IEC, 2009, p. 39) 9. ‘license_linkage’ Bu eleman, ürün kurulumu için gerekli olabilecek uygun yazılım yetki yapısını kararlaĢtırmaya yardım edecek bilgiler taĢır. Bu eleman içindeki alt elemanlar, ürünün nasıl kurulduğu ve ürünün keĢfedildiği sistemdeki güncel lisans durumu hakkında bilgiler taĢır. SAM süreci boyunca, yetkisiz yazılımların kolaylıkla tespit edilebilmesini sağlar. (ISO/IEC, 2009, p. 40) 10. ‘package_footprint’ Bir ürünün kurulmuĢ olduğuna iĢaret eden, dosyalar, registry girdileri ve bu tarz varlıklarının bir listesini tutar. Bu sadece bilgi amaçlı bir elemandır. Bu eleman, yazılımın kurulumunun tamamlanmıĢ olduğunu ya da yazılımın aktif olarak çalıĢtırıldığını doğrulamak amacıyla kullanılmaz. (ISO/IEC, 2009, p. 42) 11. ‘packager’ Kurulum prosedürleri doğrultusunda yazılım paketini kimin değiĢtirdiğinin detaylarını tutar. Bu eleman, yazılım hangi Ģirket için yapılandırılıyorsa, o Ģirketteki release manager tarafından kullanılır. (ISO/IEC, 2009, p. 45) 12. ‘product_category’ Bu eleman tagin temsil ettiği ürünün hangi ürün kategorisine ait olduğunu belirtmek amacı ile kullanılır. United Nations Standard Products and Services Code (UNSPSC) tarafından standartlaĢtırılmıĢ bir sınıflandırma/grup listesi vardır. Ürün kategorilendirmesi UNSPSC kodları kullanılarak yapılmalıdır. (ISO/IEC, 2009, p. 46) 13. ‘product_family’
p. 47) 14. ‘product_id’ Ürünün kimliğidir. Ürünün versiyonundan bağımsızdır. Ürünlerin isimleri pazarlama veya benzer stratejiler dolayısıyla sürümler arasında değiĢebilmektedir. Geriye doğru iz sürmek için ürünlere product_id verilebilir. Bu eleman ürünün yaĢam döngüsü boyunca kullanılabilecek bir kimlik olmalıdır. Yazılımın üretimi dahilinde benzersiz olmalıdır. Dünya çapında benzersiz olması gerekmez. (ISO/IEC, 2009, p. 47) 15. ‘release_date’ Bu tag genellikle, ITIL release süreci dahilinde yazılım tüketicileri tarafından kullanılır. Tarih, configuration item‟ın kurulum için piyasaya sürüldüğü tarihtir. (ISO/IEC, 2009, p. 48) 16. ‘release_id’ Bu tag genellikle, ITIL release süreci dahilinde yazılım tüketicileri tarafından kullanılır. ĠliĢkili yazılım yetkileri ve kurulum üzerine paket özelliklerini temsil etmek adına kullanılır. (ISO/IEC, 2009, p. 48) 17. ‘release_package’ Bu tag genellikle, ITIL release süreci dahilinde yazılım tüketicileri tarafından kullanılır. Servis sağlayıcının sistem mimarisi, servis yönetimi ve altyapı tanımlamaları ile uyumlu olması açısından doğrulama bilgisinin tutulmasını sağlar. (ISO/IEC, 2009, p. 49) 18. ‘release_rollout’ Yazılımı kimin “dağıtılabilir” olarak onayladığını ve bunun ne zaman gerçekleĢtirildiğini tutar. (ISO/IEC, 2009, p. 49) 19. ‘release_verification’
ortamında release paketi test edilir ve bu eleman da testten çıkan onay bilgisini tutar. (ISO/IEC, 2009, p. 50) 20. ‘serial_number’ Benzersiz tanımlama numarası; sayılar, harfler ya da sembollerden oluĢur. Belirli bir baĢlık ve satın alım için bir tanımlama amacıyla kullanılan benzersiz bir numaradır. Software identification tag perspektifinde, unique_id birincil tekil id sayılmasına rağmen çoğu organizasyon kullanılabilir olduğu durumlarda serial_number‟ı kullanır. (ISO/IEC, 2009, p. 51) 21. ‘sku’ Stock Keeping Unit (SKU), yazılım sağlayıcıları için benzersiz tanımlama numarasıdır. SKU, sayılar, harfler ve sembollerin kombinasyonundan oluĢabilir. SKU genellikle, belirli bir satın alım bilgisinin tutulması için kullanılan benzersiz bir numaradır. (ISO/IEC, 2009, p. 51) 22. ‘software_creator_alias’ SAM practitioner ve SAM tool providerların, tagde belirtilen yazılımın yaratılmasında önceden hangi Ģirketlerin ilgili olduğunu tanımlamasına olanak sağlar. Yazılımın önceki versiyonunu yaratan Ģirketin, yazılımın daha sonraki versiyonlarını yaratması için baĢka Ģirketlere izin verdiği durumlarda gereklidir. (ISO/IEC, 2009, p. 52) 23. ‘software_licensor_alias’ SAM practitioner ve SAM tool providerların, tagde belirtilen yazılımın lisanslanmasında önceden hangi Ģirketlerin ilgili olduğunu tanımlamasına olanak sağlar. Yazılımın önceki versiyonunu yaratan Ģirketin, yazılımın daha sonraki versiyonlarını yaratması için baĢka Ģirketlere izin verdiği durumlarda gereklidir. (ISO/IEC, 2009, p. 53) 24. ‘supported_languages’ Program arayüzünün kullanıcıya sunduğu dilleri ifade amacıyla kullanılır. (ISO/IEC, 2009, p. 54)
belirtilen yazılımın taglerinin yaratılmasında, önceden hangi Ģirketlerin ilgili olduğunu tanımlamasına olanak sağlar. (ISO/IEC, 2009, p. 54) 26. ‘tag_creator_copyright’ Belirli bir tag için, tag yaratıcısına telif hakkı belirleme Ģansı sağlar. Tag yaratıcılarının taglerinin toplanıp dağıtılmasına, tag yaratıcı bilgisinin belirtilmesi Ģartıyla izin vermeleri beklenir. Bu tag sayesinde, SAM tool providerlar ve baĢkaları tagleri kendi toolları içerisinde kullanabilirler. (ISO/IEC, 2009, p. 55) 27. ‘tag_version’ Bu tag, tagin versiyon bilgisinin tutulmasını sağlar. Her software identification tag benzersiz olduğundan dolayı, taglerin versiyon numarasına sahip olması aslında gerekli değildir. Ancak, yazılımın yaĢam döngüsü boyunca, software identification tagler de değiĢtiğinden, düzenlendiğinden, eklenip silindiğinden dolayı software identification taglerin de versiyonlarının tutulmasına gerek duyulabilir. (ISO/IEC, 2009, p. 56) 28. ‘upgrade_for’ Bir önceki versiyonu, bir alt seviye versiyonu, temsil eden ürün baĢlığıdır. Neyin upgrade edildiğine dair spesifik bir bilgi tutar. (ISO/IEC, 2009, p. 57) 29. ‘usage_identifier’ Ürünün kullanıp kullanılmadığını anlamak için nasıl bir süreç kullanılacağını ifade etmek için kullanılır. (ISO/IEC, 2009, p. 57) 30. ‘validation’ Software identification tagin bozuk mu sağlıklı mı olduğunun anlaĢılması için bazı doğrulama aĢamalarından geçirilmesi gerekir. Bu tag, bu doğrulama aĢamaları ile ilgili, zaman ve sonuç bilgilerini tutar. (ISO/IEC, 2009, p. 59)
takdirde kullanıcılar “extended_information” elemanının altına kendi bilgilerini ekleyerek .swidtag standardını geniĢletebilirler. Bu bilgiler XML yapısında olmalıdır. Bu bilgileri doğrulayabilmek için istenirse ek XSD dosyalarına referanslar da gösterilebilir. (ISO/IEC, 2009, p. 60) Standartların RBT Varlıklarının Ontoloji Tabanlı İzlenmesi ve Yönetimi Projesinde Kullanımı Konusunda Yorumlar ISO/IEC 19770 standartlarının bu proje kapsamında incelenip araĢtırılmasındaki temel amaç, Ģirket bünyesindeki yazılımların birbirleriyle iliĢkilerini ve yazılımlar arasındaki etki-tepki mekanizmalarını bir standart kapsamında ele alabilme isteğidir. Ancak ISO/IEC 19770 standardı içeriği dolayısıyla bu konudaki beklentileri yeterli seviyede karĢılayamamıĢtır. Proje kapsamında beklenilen, yazılımlar arasındaki iliĢkilerin ve etki-tepki mekanizmalarının kolay incelenebilirliğidir. Fakat ISO/IEC 19770 standartları, Ģirket ağında yer alan yazılım, donanım bileĢenlerinin ve bunların yanında Ģirket çalıĢanları da dahil olmakla beraber bu bileĢenlerle etkileĢime giren her türlü varlığın yönetiminden sorumludur. Projede elde edilmesi amaçlanan sonuçların perspektifi ile standartların elde etmeyi amaçladığı sonuçların perspektifi tam anlamıyla örtüĢmemiĢtir. Temel amaç doğrultusunda kullanılacak olmasa bile bu standart, projenin ilerleyen dönemlerinde oluĢturulan ontolojinin tutarlılığının devamlı olabilmesi için sağlanması gereken doğru ve tam bilgilerin sağlanıp, bu bilgilerin sürekliliğini devam ettirmek adına yazılımların yönetimini sağlayacak bir metodoloji geliĢtirme konusunda kaynak olarak kullanılmalıdır. ISO/IEC 19770 standardı çıkacak üçüncü bölümüyle beraber git gide lisans yönetimine ağırlık vereceğinden dolayı Ģirketin yazılım yönetim prosedürleri oluĢturulurken bu standardı tamamen uygulamaya koymak yerine sadece gerekli süreçlerin uygulama dahiline alınması önerilmiĢtir.
SAM konusundaki bilgi birikimi ile ISO/IEC 19770 standartlarının kavram haritası çıkarılmaya baĢlanmıĢtır. ITIL bu konuda yol gösterici olmuĢ, ancak yoğunlukla faydalanılmamıĢtır. Proje genelinde kavram haritalarının çıkarılması için öncelikli olarak Freemind yazılımı üzerinde durulmuĢtur. Ancak bu yazılımın sunduğu özelliklerin yetersiz kalıĢı ve kullanımının zorluğu nedeniyle bu yazılım terkedilmiĢ ve kavram haritaları Mindjet Mindmanager yazılımı ile geliĢtirilmiĢtir. Yaptığımız çalıĢmalar sonucunda ISO/IEC 19970-1 ve ISO/IEC 19970-2 standartlarını temsil eden bir kavram haritası tamamlanmıĢtır. Bu harita TÜPRAġ tarafından hazırlanan Rafineri Bilgi Teknolojileri varlıkların düzenini gösteren kavram haritasının ISO standartlarına olan yakınlığını tespit etmek ve bu haritayı birleĢtirmek amacıyla kullanılmıĢtır. Ġlerleyen kısımda ISO/IEC 19770 standartları temel alınarak hazırlanmıĢ SAM kavram haritası tanıtılacaktır. ISO/IEC 19770 Kavram Haritası ISO/IEC 19770 kavram haritası standartların incelenmesi sonucu oluĢturulmuĢ, standartta geçen terimlerin ve yapılması gereken süreçlerin birbirleriyle olan iliĢkilerinin gösterilmeye çalıĢıldığı bir çizelgedir. Standardın “Terms and Definitions” kısmındaki tüm kavramlar haritaya eklenmeye çalıĢılmıĢtır. Bu kavram haritasındaki tüm terim ve iliĢkiler ilerleyen sayfalarda anlatılacaktır. Kavram haritasının okunması Kavram haritası daha kolay anlaĢılması açısından renklendirilmiĢtir. Aynı zamanda, kavram haritası bilgisayar ortamında açıldığında tüm terimlerin açıklamalarına da üzerlerine tıklanarak eriĢilebilmektedir. Ağaç Ģeklinde görülen girdiler “Organization” temel olmak üzere, birer kavramdır. Bir kavramdan diğer kavrama giden oklar iliĢkileri göstermektedir. Bu iliĢki oklarının üstündeki isimler, ISO standartlarında o iliĢki için tanımlanmıĢ isimi göstermektedir.
“Terms and Definitions” kısmında açıklaması ayrıca yapılmamıĢtır. Standartların uygulanmaya çalıĢıldığı organizasyonu temsil etmektedir. Software asset management ISO/IEC 19770-1 3.12 ve ISO/IEC 19770-2 4.1.26 kısımlarında tanımlanmıĢtır. Kavram haritasında yazılım varlıklarının yönetim sürecini temsil etmektedir. Ayrıntılı bilgi için bkz. Software Asset Management Nedir? s.27 Procedure ISO/IEC 19770-1 3.9 kısmında tanımlanmıĢtır. Bir iĢi tamamlamanın önceden resmi olarak belirlenmiĢ yolu, yöntemi anlamına gelmektedir. Prosedürlerde kimin tarafından, hangi sırayla, neyin yapılacağı ve çıktıların ne olacağı çok ayrıntılı bir Ģekilde bellidir. Prosedür, süreçten daha detaylı bir tanımlama biçimidir. (ISO/IEC, 2006, p. 4) Kavram haritasında bu kısmın altına Ģirketin geliĢtirmiĢ olduğu kendi prosedürleri eklenmelidir. Process ISO/IEC 19770-1 3.10 kısmında tanımlanmıĢtır. Girdileri çıktılara dönüĢtüren bir dizi aktiviteyi tanımlamaktadır. Proseslerde genel bir akıĢ, aktivite listesi verilmekte her iĢ ayrıntılarıyla tanımlanmamaktadır. Sürecin daha ayrıntılı olan haline prosedür denmektedir. (ISO/IEC, 2006, p. 4) Kavram haritasında bu kısmın altına tezde SAM süreçleri (bkz. s. 31) kısmında tanıtımı olan süreçler eklemelidir. Yer sıkıntısından dolayı bu kısım kavram haritasında gösterilmemiĢtir. Employee Organizasyon bünyesinde çalıĢan ve SAM ile bir Ģekilde alakası olan personelleri temsil etmektedir. Standartlarda geçen bir terim değildir. Sam ile
kavram haritasına eklenmesi tarafımızdan uygun görülmüĢtür. Corporate Board or Equivalent Body ISO/IEC 19770-1 3.3 kısmında tanımlanmıĢtır. ġirketin yönetiminden sorumlu, bu sorumluluğu yasal olarak da bulunan, en üst düzey yönetici, yöneticilerdir. (ISO/IEC, 2006, p. 3) Genel müdür, “patron” veya yönetim kuruluna karĢılık gelmektedir. SAM owner ISO/IEC 19770-1 3.11 ve ISO/IEC 19770-2 4.1.23 kısmında tanımlanmıĢtır. Organizasyon bazında SAM‟den sorumlu olarak kabul eden çalıĢandır. (ISO/IEC, 2006, p. 4) (ISO/IEC, 2009, p. 9) SAM owner tüm Software Asset Management yönetiminden sorumlu olduğundan, bu iki kavram arasındaki sorumluluk iliĢkisi kavram haritasında belirtilmiĢtir. SAM owner Yönetim Kurulu‟na rapor vermektedir. Bu iki kavram arasındaki rapor verme iliĢkisi kavram haritasında belirtilmiĢtir. Local SAM owner ISO/IEC 19770-1 3.7 kısmında tanımlanmıĢtır. Organizasyonun belirli kısımları için yönetici sorumluluklarına sahip yerel SAM yöneticileridir. SAM yöneticisi tarafından seçilip sorumlulukları belirlenmektedir. (ISO/IEC, 2006, p. 4) Local SAM ownerlar sürekli olarak SAM owner‟a rapor vermektedirler. Bu iki kavram arasındaki iliĢki karam haritasında belirtilmiĢtir. SAM practitioner SO/IEC 19770-2 4.1.24 kısmında tanımlanmıĢtır. Yazılım varlıklarının yönetiminden sorumludurlar. (ISO/IEC, 2009, p. 9)
olan çalıĢanları kapsamaktadır. (ISO/IEC, 2006, p. 4) Release manager ISO/IEC 19770-2 4.1.22 kısmında tanımlanmıĢtır. DeğiĢiklik yapılmıĢ ve yeni CI‟ların üzerlerinde gerekli testlerin yapılarak organizasyonun çalıĢma ortamına alınmasından sorumlu kiĢidir. (ISO/IEC, 2009, p. 9) Software provider ISO/IEC 19770-2 4.1.37 kısmında tanımlanmıĢtır. Dağıtmak ya da kurulum içinde kullanılmak üzere yazılım geliĢtiren (software creator), yazılımı düzenleyen (software modifier) ya da lisanslama yapan (software licensor) kuruluĢtur. (ISO/IEC, 2009, p. 11) “Yazılım sağlayıcı” olarak TürkçeleĢtirilebilir. Software consumer ISO/IEC 19770-2 4.1.27 kısmında tanımlanmıĢtır. Bir yazılım paketinin kullanım haklarını satın alan organizasyon ya da kiĢidir. (ISO/IEC, 2009, p. 9) “Yazılım tüketicisi” olarak TürkçeleĢtirilebilir. Kavram haritasında bu kavram Organization ile Software Provider arasında bir iliĢki olarak gösterilmiĢtir. Organization Software Provider tarafından sağlanan yazılımları “tüketmektedir”. Customer ISO/IEC 19770-2 4.1.7 kısmında tanımlanmıĢtır. Yazılım yayımcılarının tasarlayıp geliĢtirdiği yazılımların kullanım haklarını satın alan organizasyonlar ya da son kullanıcılardır. (ISO/IEC, 2009, p. 7) “MüĢteri” olarak TürkçeleĢtirilebilir. Kavram haritasında bu kavram Organization ile Software Provider arasında bir iliĢki olarak gösterilmiĢtir. Organization Software Provider‟ın “müĢterisidir”. Tag provider ISO/IEC 19770-2 4.1.41 kısmında tanımlanmıĢtır. Yazılım paketleri için software identification tagleri yaratan (tag creator) ya da yeniden düzenleyen (tag modifier) Ģirkettir. Bu Ģirket üçüncü parti bir Ģirket olabileceği gibi kurumun kendisi de olabilir. (ISO/IEC, 2009, p. 11)
tagleri ilk defa yaratan Ģirkettir. Bu Ģirket yazılımın kendisini yazan Ģirketle aynı Ģirket olabileceği gibi üçüncü parti bir Ģirket de olabilir. (ISO/IEC, 2009, p. 11) Tag modifier ISO/IEC 19770-2 4.1.40 kısmında tanımlanmıĢtır. Software identification tagler yaratıldıktan sonra onları yeniden düzenleyen Ģirkettir. Bu bir software packager ya da software consumer olabilir. (ISO/IEC, 2009, p. 11) Software identification taglerin düzenlenmesi bu standarttaki kurallara göre yapılmalıdır. Her rol, tagin tamamının düzenlemeye yetkili değildir. Software manufacturer ISO/IEC 19770-2 4.1.34 kısmında tanımlanmıĢtır. Dağıtım için veya diğer kiĢi ya da organizasyonların kullanması için yazılım geliĢtiren kiĢiler ya da organizasyondur. (ISO/IEC, 2009, p. 10) Software creator ISO/IEC 19770-2 4.1.28 kısmında tanımlanmıĢtır. Yazılım ürünü veya yazılım paketi yaratan kiĢi ya da organizasyondur. Software Creator‟un yazılımı yaratmıĢ olması, yazılımı satma veya dağıtma hakkına sahip olduğu anlamına gelmez. (ISO/IEC, 2009, p. 9) Örneğin, yapılan kontrat ile B firması C firması için X yazılımını geliĢtiriyor olabilir. B firması yazılımı geliĢtiren olduğu halde, hak sahibi C firmasıdır. Software developer ISO/IEC 19770-2 4.1.29 kısmında tanımlanmıĢtır. Yazılımı geliĢtiren insandır. (ISO/IEC, 2009, p. 10)
tanımlanmıĢtır. Belirli bir iĢ (business) alanında uzmanlaĢmıĢ yazılım geliĢtiricilerdir. (ISO/IEC, 2009, p. 8) Software modifier Bu kavram doğrudan bir tanım olarak yer almamaktadır. Ancak standart içerisinde baĢka kavramlarla beraber geçmekledir. Software modifier herhangi bir sebepten dolayı yazılımı düzenleyen kuruma verilen addır. Örneğin, birçok yazılımı paket halinde sunmak için yazılımların üzerlerinde değiĢiklik yapılabilir. Software publisher ISO/IEC 19770-2 4.1.36 kısmında tanımlanmıĢtır. Yazılımı paketleyen ve dağıtımını yapan insan, grup ya da Ģirkettir. Software Publisher, Software Manufacturer ile aynı olabilir. (ISO/IEC, 2009, p. 11) Software packager ISO/IEC 19770-2 4.1.36 kısmında tanımlanmıĢtır. BaĢkaları tarafından geliĢtirilmiĢ yazılımları yeniden paketleyen kuruluĢtur. (ISO/IEC, 2009, p. 10) Value-added reseller ISO/IEC 19770-2 4.1.45 kısmında tanımlanmıĢtır. Var olan ürünleri, birleĢik yazılım paketleri olarak yeniden paketleme ve bu paketlere teknik destek sağlama lisansına sahip Ģirkettir. (ISO/IEC, 2009, p. 12) Software licensor ISO/IEC 19770-2 4.1.33 kısmında tanımlanmıĢtır. Bir yazılım veya yazılım paketi için yazılım lisansı verme hakkına sahip kiĢi veya kuruluĢtur. (ISO/IEC, 2009, p. 10) Software entitlement ISO/IEC 19770-2 4.1.30 kısmında tanımlanmıĢtır. Yazılımı satın alan ve yazılımın telif haklarının sahibi arasında yapılan anlaĢma ile, yazılımın kullanım lisansının satın alınmasıdır. (ISO/IEC, 2009, p. 10)
Her CI‟ın özelliklerini ve CI‟lar arasındaki önemli iliĢkileri içeren veritabanıdır. (ISO/IEC, 2009, p. 7) Configuration item ISO/IEC 19770-1 3.2 ve ISO/IEC 19770-2 4.1.5 kısmında tanımlanmıĢtır. Tek bir varlık olarak yönetilecek olan donanım birleĢimi ya da yazılım birleĢimi ya da her ikisinin birden birleĢimi olan parçacık anlamına gelmektedir. CI, ITIL kapsamında çok ayrıntılı bir Ģekilde anlatılmıĢtır. Ancak CI‟a SAM değil de ITIL kapsamında bakıldığında CI‟lar sadece donanım ve yazılım bileĢenlerini değil, kiĢiler de dahil olmak üzere diğer tüm varlıkları kapsamaktadır. Ayrıntılı bilgi için bkz. Configuration Management s. 10 End-User ISO/IEC 19770-2 4.1.9 kısmında tanımlanmıĢtır. Yazılım paketlerini yönetmek ya da kullanmak için computing device ile doğrudan etkileĢime geçen ya da computing device‟ı iĢleten insan ya da insanlardır. (ISO/IEC, 2009, p. 7) “Son kullanıcı” olarak TürkçeleĢtirilebilir. Kavram haritasında bu kavram Employee ile CI arasında bir iliĢki olarak gösterilmiĢtir. CI‟ların “son kullanıcısı” Employee‟lardır. Platform ISO/IEC 19770-2 4.1.17 kısmında tanımlanmıĢtır. Üzerine yazılımların yüklenip çalıĢtırılabileceği bilgisayar, donanım ve/veya bu donanımlara bağlı iĢletim sistemi, sanal makine. (ISO/IEC, 2009, p. 8) Örnek olarak Linux, Microsoft Windows ve Java verilebilir. Platform provider ISO/IEC 19770-2 4.1.18 kısmında tanımlanmıĢtır. Platformu sağlayan organizasyondur. Bu organizasyon genellikle iĢletim sistemi veya sanal ortamın üreticisidir. Bu özellik, doğrudan Platform‟un bir özniteliği olduğundan kavram haritasında ayrıca belirtilmemiĢtir.
programların, prosedürlerin, kuralların ve iliĢkili dokümanların toplamıdır. (ISO/IEC, 2009, p. 9) (Program çalıĢan EXE olarak, Software ise, dokümantasyonu, kutusu lisansı, kurulum CD‟si ile program ile alakalı her Ģeyin toplamı olarak düĢünülebilir.) Software identification tag ISO/IEC 19770-1 3.14 kısmında Software Tag olarak ve ISO/IEC 19770-2 4.1.31 kısmında software identification tag olarak tanımlanmıĢtır. Software Identification Tag, ISO/IEC 19770-2 standardı çerçevesinde çok ayrıntılı bir biçimde incelenmiĢtir. Ayrıntılı bilgi için bkz. ISO/IEC 19770-2: Software Identification Tag s. 47 Tag Provider‟lar Software Identification Tagleri sağlamakla sorumludurlar. Bu, kavram haritasında iliĢki olarak gösterilmiĢtir. Element ISO/IEC 19770-2 4.1.8 kısmında tanımlanmıĢtır. Software Identification Tag‟ın içerisinde temsil edilen her bir bilgi parçasıdır. (ISO/IEC, 2009, p. 8) Bu bilgilerin ne olabileceği ISO/IEC 19770-2 standardı çerçevesinde çok ayrıntılı bir biçimde incelenmiĢtir. Ayrıntılı bilgi için bkz. .swidtag s. 54 Uniform resource identifier (URI) ISO/IEC 19770-2 4.1.42 kısmında tanımlanmıĢtır. Internet‟te eriĢilebilir olan fiziksel ya da soyut kaynakları tanımlayan karakterler dizisidir. URI söz dizimi IETF RFC 3986 standardı ile tanımlanmıĢtır. (ISO/IEC, 2009, p. 11) XML ISO/IEC 19770-2 4.1.11 kısmında tanımlanmıĢtır. Özgür lisanslı, platform bağımsız veri tutmak için kullanılan bir markup dilidir. Kavram haritasında belirli bir XSD Ģemasına bağlı olarak software identification tag bilgilerinin tutulduğu dosya formatı olduğu için yer almaktadır. (ISO/IEC, 2009, p. 8)
dokümanlarında hangi elementlerin olup olmayacağını, bu elementlerin alacakları verileri ve sırası gibi kuralları belirleyen dokümandır. Bir XML dokümanı belirtilen XSD dokümanındaki kurallara uygunsa, o XML dokümanı “valid” olur. (ISO/IEC, 2009, p. 12) Registration identifier ISO/IEC 19770-2 4.1.20 kısmında tanımlanmıĢtır. Domain adı, domainin alındığı tarih ve eklenebilecek diğer Ģirkete özgü bilgiler ile oluĢturulmuĢ benzersiz bir göstericidir. Böylece her kurum bir standart çerçevesinde diğerinden ayrı bir benzersiz kimlik dizisine sahip olacaktır. (ISO/IEC, 2009, p. 9) Bu kısım ISO/IEC 19770-2 kapsamında detaylı bir Ģekilde açıklanmıĢtır. Ayrıntılı bilgi için bkz. Unique registration ID (regid) s. 54 Message-digest algorithm 5 ISO/IEC 19770-2 4.1.15 kısmında tanımlanmıĢtır. MD5 olarak kısaltılabilmektedir. Genelde iki dosyanın aynı veriyi taĢıyıp taĢımadığına karar vermek için kullanılan 128 bitlik hash değeri kullanan kriptografik hash fonksiyonudur. Tek yönlü çalıĢmaktadır. (ISO/IEC, 2009, p. 8) Globally unique identifier (GUID) ISO/IEC 19770-2 4.1.12 kısmında tanımlanmıĢtır. Çok yüksek ihtimalle benzersiz olan 16 baytlık metin dizisidir. Regid yerine kullanılabilecek bir alternatif benzersiz kimlik yaratma yöntemidir. (ISO/IEC, 2009, p. 8) Tezimiz kapsamında, mümkün olduğu sürece GUID yerine Regid kullanımını önermekteyiz. Software header ISO/IEC 19770-1 3.13 kısmında tanımlanmıĢtır. Yazılım ile ilgili yönetimsel bilgileri saklayan, yazılıma doğrudan gömülmüĢ bilgilerdir. (ISO/IEC, 2006, p. 4)
hakkı sahibinin belirttiği Ģartlar ve koĢullara uygun, yazılımın yasal kullanım haklarıdır. (ISO/IEC, 2009, p. 10) Yazılım lisansı ile yazılım lisanslayıcısı birbirleriyle doğrudan iliĢkilidir. Bu iliĢki kavram haritasında gösterilmiĢtir. Underlying license ISO/IEC 19770-1 3.15 kısmında tanımlanmıĢtır. Alınan yazılımların tabi oldukları kullanım Ģartlarıdır. (ISO/IEC, 2006, p. 14) Bu lisansların birleĢtirilmesi ile “effective full license” ler çıkarılabilmektedir. Effective full license ISO/IEC 19770-1 3.6 kısmında tanımlanmıĢtır. Bir veya birden fazla “underlying license” nin birleĢtirilmesi ile oluĢturulabilecek lisanslardır. (ISO/IEC, 2006, p. 4) Örneğin bir firmanın iki farklı lisanslı ürünün satın alınması halinde, bu firmanın diğer ürünlerinden bazılarına ücretsiz olarak eriĢilebilmesi iki lisansın birleĢtirilerek yeni eriĢim haklarına, yeni lisanslara sahip olmaya bir örnektir. Version ISO/IEC 19770-2 4.1.46 kısmında tanımlanmıĢtır. Yazılımın bir revizyonunu gösteren harf ve rakamların birleĢimidir. Genellikle bir versiyon numarası birden çok parçadan oluĢmaktadır. (ISO/IEC, 2009, p. 12) Bundle ISO/IEC 19770-2 4.1.2 kısmında tanımlanmıĢtır. Pazarlama veya lisanslama stratejisi açısından birden fazla ürünün tek bir parça halinde satıĢının yapılmasıdır. (ISO/IEC, 2009, p. 6)
veya birden çok görsel iĢleme özelliğini sunan “Adobe Master Collection” örnek verilebilir. Application ISO/IEC 19770-2 4.1.1 kısmında tanımlanmıĢtır. Verileri toplayan, kaydeden, iĢleyen ve sunan yazılım bileĢenleridir. (ISO/IEC, 2009, p. 6) Uygulama, kavram haritasında farklı konumlara da yerleĢtirilebilir. Bu kavramın “Bundle” altında yerleĢtirilmesi ile, “Bundle”ın çeĢitli “Apllication”lardan, bu “Application”ların da çeĢitli “Component”lerden oluĢtuğunun ifade edilmeye çalıĢılmasıdır. Component ISO/IEC 19770-2 4.1.3 kısmında tanımlanmıĢtır. Belirli bir iĢi yapan, birbirinden ayrılabilen ufak uygulama parçalarıdır. (ISO/IEC, 2009, p. 7) .NET assembly‟leri veya bazı uygulamaların modüllerden oluĢmaları componentlere örnek verilebilir. Component ile Application arasında whole/part iliĢkisi bulunmaktadır. Legacy software ISO/IEC 19770-2 4.1.13 kısmında tanımlanmıĢtır. Software identification tagleri olmadan yaratılmıĢ, ISO/IEC 19770-2 standardına uygun olmayan yazılımlardır. (ISO/IEC, 2009, p. 8) Computing device ISO/IEC 19770-2 4.1.4 kısmında tanımlanmıĢtır. Önemli iĢlemleri gerçekleĢtiren fonksiyonel ünitedir, insan müdahalesi olmadan çeĢitli aritmetik ve mantıksal iĢlemleri yerine getirir. (ISO/IEC, 2009, p. 7) “Donanım” olarak düĢünülebilir. Definitive master version ISO/IEC 19770-1 3.4 kısmında tanımlanmıĢtır. Sistemlere yazılımları yüklemek amacıyla kullanılacak dağıtım kopyalarının hazırlandığı ana kopyalardır. (ISO/IEC, 2006, p. 3)
yüklemek amaçlı kullanılan dağıtım kopyalarıdır. (ISO/IEC, 2006, p. 3) Distributable item Bu kavram doğrudan bir tanım olarak yer almamaktadır, ancak ISO dokümanında baĢka kavramlarla beraber geçmektedir. Tek baĢına sisteme dağıtım/yükleme yapılabilecek, yapılması mantıklı yazılım/yazılım grubudur. Package ISO/IEC 19770-2 4.1.35 kısmında tanımlanmıĢtır. Dağıtıma hazır “Distributable Item” parçalarıdır. Complete and documented set of programs supplied for a specific application or function. TÜPRAŞ RBT Kavram Haritası TÜPRAġ RBT kavram haritası TÜPRAġ tarafından RBT varlıklarını görebilmek ve sınıflayabilmek için hazırlanmıĢ bir haritadır. Proje kapsamında çok sayıda değiĢikliğe uğramıĢtır ve halen geliĢtirilmektedir. TÜPRAġ‟ın RBT varlıklarına ISO/IEC 19770 bakıĢ açısından bakabilmek ve perspektif kazanmak için ISO/IEC 19770 kavram haritası ile TÜPRAġ RBT Kavram Haritasının birleĢtirilmesi düĢünülmüĢtür. BirleĢtirilmiĢ harita, birleĢtirme yapılacağı zamanki son TÜPRAġ RBT kavram haritası ile bir önceki bölümde anlatılan ISO/IEC 19770 Kavram Haritalarından oluĢmaktadır. BirleĢtirilmiĢ harita anlatılmadan önce, birleĢtirme aĢamasını daha iyi özetleyebilmek için TÜPRAġ RBT kavram haritasındaki bazı kavramlar açıklanacaktır. BirleĢtirme iĢlemi yapıldığı sırada son sürüm IT_EnvironmentV2 kavram haritasıdır.
renklendirilmiĢtir. Aynı zamanda, kavram haritası bilgisayar ortamında açıldığında tüm terimlerin açıklamalarına da üzerlerine tıklanarak eriĢilebilmektedir. Ağaç Ģeklinde görülen girdiler “CI” temel olmak üzere, birer kavramdır. Kavramların sahip oldukları özellikler ve iliĢkiler açıklama kısmında belirtilmiĢ olup, ayrıca Ģekil olarak ifade edilmemiĢtir. ġekil 3: TÜPRAġ RBT kavram haritası
tanımıyla aynı anlama gelmektedir. Ayrıntılı bilgi için bkz. Configuration Management s. 10 Bu kavram haritasında her Ģey yönetilebilen birer varlık olarak görülmektedir. Central Processing Unit Central Processing Unit açılımına karĢılık gelmektedir. ĠĢlem yapan donanım parçasıdır. CPU, bazı özellik ve iliĢkileri donanımların çoğunluğundan farklı olduğu için hardware içerisine alınmamıĢtır. Software RBT kapsamındaki tüm yazılımları (iĢletim sistemleri de dahil olmak üzere) kapsamaktadır. Operating system Diğer tüm yazılımların üzerinde çalıĢtığı sistemdir. Application RBT kapsamında yönetilmesi önem taĢıyan tüm yazılımlardır. Bu yazılımlarla ilgili dosyalar, servisler ve (kullanıyorsa) kullandığı SMTP sunucusu gibi iliĢkiler önem taĢımaktadır. Application infrastructure Doğrudan bir uygulama olarak çalıĢmak yerine, uygulamalara çalıĢması için altyapı sağlayan yapılardır. Service based application infrastructure, diğer uygulamaların çalıĢırken kullandıkları servis bazlı yapılardır. Bunlara örnek olarak DHCP, DNS, Active Directory verilebilir. Framework based application infrastructure, diğer uygulamaların geliĢtirilmesine olanak veren ana çatılardır. Bunlara örnek olarak IIS, .NET ve JAVA verilebilir.
çalıĢtırılmasına olanak verecek DBMS‟lerdir. Bunlara örnek olarak SQL Server, MYSQL, DB2 verilebilir. Core application Son kullanıcı tarafından açılıp kullanılabilecek yazılımlardır. Bir ara yüzü vardır. Desktop Application, masaüstü yazılımlardır. Web Application‟lar ise tarayıcı üzerinden çalıĢırlar. Service Son kullanıcı tarafından kullanılacak bir ara yüzü olmayan, diğer uygulamalarda kullanılmak üzere hizmet sunan servislerdir. Web servisleri ve Windows servisleri olarak ikiye ayrılabilirler. Location Bir donanımın fiziksel konumunu tanımlar. Company Bir yazılım veya donanımdan sorumlu/sağlayıcısı olan üçüncü parti Ģirketleri tanımlar. Bu Ģirketlerin adresi, sorumlu kiĢi ve hangi yazılım/donanımlarla iliĢkisi olduğu önemlidir. Contract ġirketlerle yapılan lisans veya bakım anlaĢmaların tanımlar. BaĢlangıç, bitiĢ tarihleri, tanımı ve fiyatı vardır. Human TÜPRAġ RBT varlıklarından biriyle bir Ģekilde iliĢkisi olan ve bu yüzden kavram haritasına eklenen hücrelerden oluĢan, akıllı, kanlı canlı varlıktır. Yönettiği, sahip olduğu, sorumlu olduğu varlıklar ve kime rapor verdiği gibi yönetimsel bilgiler önem taĢımaktadır.
bilgilerinin ve yetkilerinin tutulması açısından önemlidir. Database DBMS‟lerde barınan veritabanlarıdır. Veritabanları ile connection string, karakter kodlaması ve bağlantı portu gibi bilgiler tutulmalıdır. File & Document File, diskte yer alan herhangi bir dosyayı temsil eder. Document ise herhangi bir belgeyi temsil eder. Logical Unit Number (LUN) SCSI eriĢimi ile ilgili bir tür tanımlama numarasıdır. Hardware RBT ile ilgili tüm donanımları kapsamaktadır. Bu donanımlar bilgisayar/sunucu (computer/server), bilgi saklama ekipmanları (storage hardware), güç kaynakları (power devices) ve ağ aygıtları (network devices) olabilir. PHD, Shadow, Buffer, USM, OPC Server, OPC Client, Tag, RDI TÜPRAġ bünyesinde kullanılan, rafineriden bilgileri almak konusunda kullanılan endüstri yazılım ve teknolojileridir. Bu kavramları sınıflandırabilmek teknik bilgi ve altyapı gerektirdiğinden dolayı ISO/IEC 19770 ile birleĢtirilerek oluĢturulan kavram haritası kapsamında yerleri değiĢtirilmemiĢ, olduğu gibi bırakılmıĢlardır. SMTP Simple Mail Transport Protocol açılımına denk gelmektedir. Bazı yazılımlar bu protokol yardımı ile uyarı göndermektedirler. Aynı zamanda kiĢiler arası mail
kavram haritasına dahil edilmiĢtir. Disk Partition Bir diskin mantıksal olarak bölünmüĢ bir bölgesidir. Ġçerisindeki dosya sistemi, kapasitesi, nasıl ulaĢılacağı ve hangi donanım üzerinde olduğu önem taĢımaktadır. TÜPRAŞ RBT kavram haritasının ISO/IEC 19770 standardına göre yorumlanması TÜPRAġ‟ın RBT varlıklarına ISO/IEC 19770 bakıĢ açısından bakabilmek ve perspektif kazanmak için ISO/IEC 19770 kavram haritası ile TÜPRAġ RBT Kavram Haritası birleĢtirmiĢtir. BirleĢtirilmiĢ harita, birleĢtirme yapılacağı zamanki son TÜPRAġ RBT kavram haritası ile önceki bölümlerde anlatılan ISO/IEC 19770 Kavram Haritalarından oluĢmaktadır. Bu kısımda (yazılım kısmı ağırlıklı olmak üzere) kavram haritaları birleĢtirilirken göz önüne alınanlar açıklanacak ve birleĢtirilmiĢ kavram haritası üzerinde durulacaktır. Kavram haritasının okunması Kavram haritası daha kolay anlaĢılması açısından renklendirilmiĢtir. Aynı zamanda, kavram haritası bilgisayar ortamında açıldığında tüm terimlerin açıklamalarına da üzerlerine tıklanarak eriĢilebilmektedir. Ağaç Ģeklinde görülen girdiler “TÜPRAġ (Organization)” temel olmak üzere, birer kavramdır. Kavramların sahip oldukları özellikler ve iliĢkiler açıklama kısmında belirtilmiĢ olup, ayrıca Ģekil olarak ifade edilmemiĢtir.
TÜPRAġ RBT Kavram Haritasındaki CI terimi içerdiği kavramlar dolayısıyla hatalı kullanılmıĢtır.1 ISO 19770'e göre bağımsız yapılandırılan her bir hardware/software parçasına CI denir. (ISO/IEC, 2006, pp. 3, 3.2) (ISO/IEC, 2009, pp. 7, 4.1.5) SAM kapsamında ele alınan CI Ģirket ve insanları içermez.2 Hem üçüncü parti Ģirketlerin varlığını ve TÜPRAġ‟tan farklılıklarını ifade edebilmek, hem CI ve CMDB (ISO/IEC, 2009, pp. 7, 4.1.6) kavramlarını SAM çerçevesinde kullanabilmek, hem de CI kavramı ile alınamayabilecek bir kavram olarak bir Ģirketin varlığını da ifade edebilmek için temel yapı olarak TÜPRAġ tanıtılmıĢtır.3 Aynı zamanda, ISO/IEC 19770 kavram haritasındaki Organization kavramının, TÜPRAġ kavramı ile birebir örtüĢtüğü görülecektir. TÜRPAġ kavramı, tüm RBT projesini temsil etmekte olup, ilerleyen zaman içerisinde baĢka kavramların (baĢka departmanların dahil olması durumunda) bu kavram haritasına kolaylıkla eklenebilmesini sağlayacaktır.4 ISO/IEC 19770-2‟de (ve ITIL'da) tüm CI'ların bir veritabanında tutulması önerilmektedir. Bu veritabanı CMDB (ISO/IEC, 2009, pp. 7, 4.1.6) olarak adlandırılmıĢtır. Bu iliĢkiyi temsil edebilmek için tüm CI'lar CMDB içine alınmıĢtır. 1 CI teriminin ISO/IEC 19770-1 standardındaki tanımı için bkz. s. 50 ve Configuration item s. 62 2 CI, ITIL kapsamında çok daha geniĢ kapsamlı kullanılmıĢtır ve yazılım/donanım dıĢındaki varlıkları da kapsamaktadır. ITIL kapsamında tanımlanmıĢ CI için bkz. Configuration Management s. 10 3 Kavramların aitlik iliĢkilerinde “belongs to TÜPRAġ” “works in TÜPRAġ” gibi iliĢkilerde ve TÜPRAġ‟ın tüzel olarak ifade edilmesi gerektiği hallerde bu kavram yararlı olacaktır. 4 BaĢka bir bakıĢ açılarına göre (örneğin ITIL) temel kavramın TÜPRAġ yerine CMDB veya CI olması geçerli bir argüman olabilir.
süreci ile kıyaslandığında çok ayrıntılı kaldığı düĢüldüğünden dolayı “Package” ve “Distributable Item” kavramları “Distribution Copy” / “Definitive Master Version” kavramları içinden kaldırılmıĢtır. Bu kısım TÜPRAġ‟ın yeni yazılım ve yazılım güncellemelerini sahadaki bilgisayara nasıl aktardığına bağlı olarak tekrar gözden geçirilmelidir. “Legacy Software” kavramı ISO/IEC 19770 kavram haritasına Software Identification Tag'ı desteklemeyen uygulamaları göstermek için kavram haritasına eklenmiĢti.1 Ancak RBT projesinde ontoloji kapsamına alınacak yazılımların bilgileri, Software Identification Tag desteklesin ya da desteklemesin bir Ģekilde mutlaka çekilecektir ve ontolojiye eklenecektir. Bu yüzden bu kavram haritasından kaldırılmıĢtır. ISO/IEC 19770'te geçen “Computing Device” terimi (ISO/IEC, 2009, pp. 7, 4.1.4) TÜPRAġ RBT kavram haritasında geçen "Hardware" terimine2 çok yakın olmasına rağmen birebir örtüĢmemektedir. ISO/IEC‟deki “Computing Device" teriminin daha soyut kaldığı ve “Hardware” kavramının kavram haritası için daha uygun olduğu düĢünülmüĢtür. TÜPRAġ RBT kavram haritasındaki “Human”3, ISO/IEC 19770 kavram haritasındaki Employee4 ile, Employee adı altında birleĢtirilmiĢtir. Human Employee‟ye göre çok geniĢ kaldığından bu isim altında birleĢtirilmeleri uygun görülmüĢtür.5 TÜPRAġ kendisi de bir “Company” olduğundan, yanlıĢ anlaĢılmaları gidermek için tasarımdaki Company, 3rd Party Organizations olarak yeniden 1 Legacy Software ve kavram haritasında kullanımı için bkz. Legacy software s.66 2 Hardware terimi ve kavram haritasında kullanımı için bkz. Hardware s.72 3 Human terimi ve kavram haritasında kullanımı için bkz. Human s. 71 4 Employee terimi ve kavram haritasında kullanımı için bkz. Employee s.58 5 Employee sadece Organizasyon bünyesinde çalıĢan kiĢileri kapsamaktadır. Employee ile üçüncü parti Ģirketlerde çalıĢan kiĢiler temsil edilememektedir. BirleĢtirilmiĢ kavram haritasında üçüncü parti Ģirketlerin hem tüzel olarak temsil edileceği öngörülmüĢtür. Aksi durumlar için kavram haritasının tekrar düzenlenmesi gerekebilir.
da kesin bir ayrım konulmuĢ oldu. ISO/IEC 19770 Kavram Haritasındaki “Software Provider” lar genellikle dıĢ bir Ģirket olduğundan 3rd Party Organizations bunun altına eklendi. Ancak TÜPRAġ bünyesinde de yazılımlar geliĢtirilmektedir. Bu, kavram haritasının bu haliyle ifade edilememektedir.1 Ontoloji geliĢtirirken bunu çözecek önlemler alınmalıdır. Software Provider kavramının altındaki kısım standarttan olduğu gibi alınmıĢtır. Ancak RBT projesi için bu kadar ayrıntılı bir yazılım sağlayıcısı kavram yapısı gereksiz bir ayrıntı olarak düĢünülmektedir. TÜPRAġ‟ın ihtiyaçları doğrultusunda buradaki ayrıntılar kırpılmalıdır. ISO/IEC 19770 içerisindeki “Software” kavramının alt parçaları ile RBT kavram haritasındaki “Software” kavramının alt parçaları incelendikleri perspektif açısından birbirlerine ters düĢmektedir. TÜPRAġ RBT‟nin kavram haritasında “kind of”, “subclass of” benzeri bir iliĢki varken, alt parçalar üsttekinin bir çeĢidi, bir türü Ģeklinde iken, ISO/IEC 19770 kavram haritasında bu iliĢki “made of” “includes” “has” gibi aitlik/özellik iliĢkisine daha yakındır. Bu yüzden ISO/IEC kavram haritasındaki kavramlar, TÜPRAġ‟ın haritası için daha çok “property” olabilecek konumdadırlar. Standarttan elde edilen bu ögeler “property” ve “relation” olarak sisteme eklenmiĢtir. Örneğin, Software Identification Tag içerisinde yer alan kavramlar Software kavramı için property olmaya çok uygundur. Bunlardan halihazırda TÜPRAġ RBT kavram haritasında property olmayanlar property olarak Software kavramına eklenmiĢtir. ISO/IEC 19770‟teki platform kavramı (ISO/IEC, 2009, pp. 8, 4.1.17) üzerinde program çalıĢtırabilen donanım (cep telefonu, iĢletim sistemi, sanal makine) anlamına gelmektedir. Bu kavram, kavram haritası için biraz genel olduğundan bu kavram kullanılmamıĢtır. 1 Eğer kavram haritası TÜPRAġ yerine, CMDB veya CI kök kavram olacak Ģekilde yeniden düzenlenirse TÜPRAġ bir Ģirket ve CI olarak ifade edilebilir. O zaman yazılımın sağlayıcısı olarak TÜPRAġ da gösterilebilir hale gelir problem çözülür. Ancak bu yaklaĢım, TÜPRAġ‟ın diğer üçüncü parti Ģirketlerle aynı özelliklere sahip olmasına neden olarak baĢka problemler yaratabilir.
Partition kavramları CI'a doğrudan kavram sayısını azaltarak kavram haritasını daha hiyerarĢik hale getirmek ve karmaĢıklığı azaltmak için Data ve Logical Things Ģeklinde iki ara kavram ile sınıflandırılmıĢtır. Bu kavramların tek amacı, ağacın dengesini sağlamak ve daha dallı budaklı olmasına olanak vermektir. “Logical Things” donanım üzerinde yapılmıĢ mantıksal yapılandırmaları temsil etmektedir. Buna dosyalar, dosya sistemler ve bunları temsil edecek kimlik numaraları tarzı Ģeyler dahildir. “Data” ise yine mantıksal bir yapılandırma olup, içerisinde bir program tarafından okunacak/yazılan formatlı veri taĢımakta olanları temsil eder. Bu nedenle dosya sistemi, data kavramının altına değilken, bit dizilerini tutan file ile, veritabanı girdilerini tutan mantıksal yapı olan veritabanı bu kavramın altında yer almaktadır. Kavram haritasında yapılan bir baĢka değiĢiklik de CPU‟nun Hardware içerisine alınmasıdır. Bazı özelliklerinden dolayı orijinal TÜPRAġ RBT kavram haritasında “Hardware” kısmına dahil edilmemiĢ olsa da, mantıksal olarak bir donanım olduğundan, kavram haritasının daha düzenli olması için buraya kaydırılmıĢtır. PHD, Shadow, Buffer, USM, OPC Server, OPC Client, Tag, RDI kavramları üzerinde herhangi bir oynama yapılmamıĢ, orijinal TÜPRAġ RBT haritasında oldukları yerde bırakılmıĢlardır.1 Tez kapsamında incelediğimiz Software Asset Management yazılımları2 ve toplantılardan edindiğimiz fikirler ile kavram haritasında baĢka iyileĢtirmeler de yapılmıĢtır. Özellikle TÜPRAġ bünyesinde geliĢtirilen yazılımlarda yazılım kütüphanelerinin (dll, jar, vs.) de kavram haritasına eklenmesinin iyi olabileceği 1 DeğiĢiklik yapılamaması ve gözden geçirememenin nedeni bu kavramlar üzerinde sınıflandırma ve düzenleme yapılabilecek kadar teknik bilgi ve altyapının bulunmamasıdır. 2 Tez kapsamında incelenen SAM yazılımları için bkz. Ek 5: Tez Kapsamında İncelenen SAM Yazılımları s. 92
kavram daha eklenmiĢtir.1 1 BaĢlangıçta program kütüphanelerinin tüm yazılımlar için tutulması öngörüldü. Ancak bu kütüphaneleri tespit edip listeleyen bir program yazıp kendi bilgisayarlarımızda çalıĢtırdığımızda on binlerce dosya ile karĢılaĢtık. Bunun yönetilebilir olmadığını görünce sadece “in-house” geliĢtirilen yazılımlar için uygulanabilir olduğu kanaatine vardık.
kavram haritasındaki modeli daha da ayrıntılı bir Ģekilde temsil etmektedir. Bu modelin ontoloji Ģeklinde oluĢturulması edinilmiĢ domain bilgisinin hem bu ontolojiden yararlanacak yazılımlar arasında, hem de TÜPRAġ bünyesinde çalıĢan departmanlar/kiĢiler arasında ortak bir domain bilgi birikimi oluĢmasını sağlayacak, ortak bir terminoloji kullanılmasına yardımı olacaktır. (Noy & McGuinness, p. 1) Bu model, herhangi bir uygulamaya kesin bir Ģekilde bağlı olmadığından (highly coupled) geliĢtirilmesi daha kolay olacağı gibi, hedef olarak da “bilgileri tutan yer” olmaktan çok verileri ve domaini temsil etme yeri olarak görev alacaktır. Ontolojinin sağladığı çıkarsamalar sayesinde kök neden analizi çok daha kolay yapılabilecektir. Kullanılan Araçlar Ontoloji geliĢtirilmeden önce, RBT projesi kapsamındaki bazı ISO standartlarının EXPRESS dili kullanılarak modellemesinden dolayı modellerin tamamının bu dille geliĢtirilip ardından ontolojiye dönüĢtürülmesi öngörülmüĢtü. Ancak EXPRESS ile ilgili kullanılmaya çalıĢılan iki aracın1 da çeĢitli problemler çıkarması, böyle bir geliĢtirilmenin yapılmasının çok ciddi problemler yaĢatabileceğini göstermiĢtir. Bu yüzden kavram haritalarının geliĢtirilmesinin ardından doğrudan ontolojiye geçilmiĢtir. Ontolojinin geliĢtirilmesi için Stanford Üniversitesi tarafından geliĢtirilen Protégé isimli yazılım kullanılmıĢtır. ġu an geliĢtirilmesi ve desteği devam eden üç sürümden 3.x, 4.x ve WebProtege arasında karar verilmesi ise ayrıca bir araĢtırma ve karar süreci gerektirmiĢtir. 1 EXPRESS desteği sunan ve üzerinde çalıĢmaya çalıĢtığımız iki araç ECCO Toolkit (Pdtec) ve Eclipse için geliĢtirilmiĢ JSDAI (JSDAI) eklentileridir. ECCO Toolkit, çok eski bir yazılım olduğundan ve 16-bit destekleyen eski iĢletim sistemlerinde çalıĢtığından kullanılması teknolojik sıkıntılar yaratacaktı. Programın artık geliĢtiriliyor olmaması da ayrı bir sıkıntıydı. JSDAI ise, tüm çabalarımıza rağmen kurulum esnasında hata vermiĢ ve kurulum hiçbir Ģekilde tamamlanamamıĢtır.
sırada WebProtege 0.5 sürüm numarasına sahipti ve “alpha” etiketi ile dağıtılıyordu. (Stanford University, 2011) WebProtege, Ġnternet üzerinden tarayıcı yardımı ile ontoloji geliĢtirmeye ve ortak olarak (collaborative) ontoloji geliĢtirmeye olanak sağlamaktadır. Henüz çok yeni bir yazılım olup, sürekli geliĢtirme aĢamasındadır. Daha alpha seviyesinde olan ve hatalar içermesi olası bu kadar yeni bir yazılım ile büyük bir proje geliĢtirmenin tehlikeli olabileceği düĢünülmüĢtür. RBT projesi kapsamında ontoloji geliĢtirilirken, aynı anda birden fazla kiĢinin aynı ontolojiyi düzenlemesinin bir ihtiyaç olabileceği öngörülmüĢtür. Birden fazla kiĢinin aynı anda aynı ontolojiyi düzenleyebilmesi (masaüstü Protégé yazılımlarından, web dahil değil) sadece Protégé 3 sürümü ile yapılabilmektedir. Protégé 3, bu çoklu çalıĢma desteğini herhangi bir eklenti olmadan sunmaktadır. Protégé 4 sürümü için herhangi bir çoklu çalıĢma desteği henüz sunulamamaktadır. (Stanford University, 2009, p. #Side_by_Side_Comparison) Collaborative Protégé, Protégé 3 üzerinde çalıĢan ancak henüz Protégé 4 ile çalıĢmayı desteklemeyen bir eklentidir. Ontolojilerde not bırakma ve kiĢiler arası mesajlaĢma, değiĢiklikleri gösterme gibi araçlar sağlayarak Protégé 3‟ün çok kiĢili kullanımının kolaylaĢtırılıp zenginleĢtirilmesi amacını taĢımaktadır. Protégé 3'de projeler istenirse veritabanlarında tutulabilirken Protégé 4'de sadece klasik proje dosyalarında tutulabilmektedir. Protégé 3 OWL 1.0 sürümünü desteklerken Protégé 4, OWL 2.0 sürümünü desteklemektedir. Protégé 3‟de SPARQL desteği bulunmaktadır. Protégé, ileriye dönük uyumluluk desteği sağlamaktadır. (forward compatibility) Ancak geriye dönük uyumluluk bazı durumlarda mümkün olmamaktadır. (backward compatibility) Bu bilgilerin tamamı göz önüne alınarak ontoloji geliĢtirilirken araç olarak Protégé 3.x serisi kullanılması uygun bulunmuĢ, projenin ilerleyen safhalarında daha yeni Protégé sürümlerine geçmenin önü açık bırakılmıĢtır.
geliĢtirilirken kullanılan metodoloji (Noy & McGuinness) kapsamında uygulanan/uygulanamayan adımların tamamı anlatılacaktır. Kapsam, competency questions Ontoloji, ISO/IEC ve RBT‟nin birleĢtirilmesi ile oluĢan kavram haritasının “Software” kısmını kapsamaktadır. RBT projesinin Ģu evresinde competency sorularının çıkarılmasının güç olması nedenleriyle (kavram haritası da yeterince net olduğu için) bu sorular çıkarılmamıĢtır. GeliĢtirilen ontoloji, ileride yeni revizyonlarla iyileĢtirilmesi gereken “ilk taslak ontoloji” olarak görülmeli ve buna göre değerlendirilmelidir. ġekil 6: Kavram haritasının ontoloji kapsamında kalan kısmı
yönetimi ile ilgili ve/veya kapsam haritasındaki terimleri içeren benzer perspektifli bir ontoloji bulunamamıĢtır. Bu yüzden metodolojinin bu adımını uygulamak mümkün değildir.2 Önemli terimlerin belirlenmesi Metodolojide orijinal haliyle “Enumerate important terms in the ontology” olarak geçmektedir. Ontolojide geçmesi muhtemel önemli terimlerin listelenmesi adımını kapsamaktadır. BirleĢtirilmiĢ kapsam haritası içerisinde hem class olmaya aday, hem de property olmaya aday tüm terimler zaten listelenmiĢtir. Bu adım bu Ģekilde tamamlanmıĢtır. Sınıf hiyerarşisinin oluşturulması Kavram haritasındaki kavram hiyerarĢisi aynı zamanda sınıf hiyerarĢini de oluĢturmaktadır. BaĢlangıç olarak, kavram haritasındaki kavramlar aynı düzen içerisinde olduğu gibi ontolojiye aktarılmıĢtır. Düzenleme esnasında ihtiyaç hissedilmesi halinde oynamalar yapılmıĢtır. Hardware ve Company gibi birçok kavram doğrudan Thing‟in altında bulunmaktadır. Software dıĢındaki kavramlar için kavram haritası göz önüne alınarak herhangi bir hiyerarĢik yapı kurulmamıĢtır. Bunun nedeni, bu ontolojinin yazılım kısmına odaklanmasıdır. Ontolojinin diğer kısımlarının geliĢtirilmesi/diğer ontolojilerin yazılıp birleĢtirilmesi sonucunda bu kavramlar ayrıca zaten düzenlenecektir. 1 AraĢtırmalarda Google ve semantik arama motoru olan Swoogle kullanılmıĢ, bunlar dıĢında özellikle ISO/IEC 19770 standartları konusunda yapılan araĢtırmalarda da ontolojilere rastlanmamıĢtır. 2 Ġlerleyen aĢamalarda entegrasyon için ve bazı kavramları hazır ontolojiler yardımıyla ifade edebilmek için SKOS ve FOAF araĢtırılması gereken konular arasındadır.
verilmemiĢtir. Definitive Master Version ile Distribution Copy kavram haritasındaki subclass iliĢkisine ontolojik açıdan bakıldığında uymamaktadır. Bu yüzden bu iki kavram SetupMedia isimli bir classa sibling olarak eklenmiĢtir. Ancak aslında her Definitive Master Version‟un aynı zamanda dağıtım kopyası olarak da kullanılabileceği düĢünülerek, bu da ontolojiye yansıtılmıĢtır. Tezin önceki kısımlarında anlatılan çekincelerden dolayı, Employee yerine Human kullanılması uygun görülmüĢtür. (ayrıntılı bilgi için bkz. Birleştirme notları s.83) Application Infrastructure içerisinde bazı temel servisler ve DMBS‟ler de yer almaktadır. Bu kavramların çalıĢabilen uygulamalar ile birlikte düĢülmesinin uygun olmadığını düĢünülerek daha ileriki zamanlarda ele alınmak üzere kaldırılmıĢtır. Framework Application‟lar ise, aynı web ve desktop applicationlarda olduğu gibi çıkarsama yöntemi ile bunabilecektir. Bu açıdan bakılarak yazılımlar Service, FrameworkBased, DesktopApplication ve WebApplication olarak sınıflara ayrılmıĢtır. Ayrıca Service ve WebApplication sınıfları birleĢtirilerek WebService elde edilebilmektedir. Bir yazılım kategori olarak bunların birden fazlasına girebilecektir. Application ve OperatingSystem sınıflarının bir de sonunda KB bulunan halleri mevcuttur. Bunun ne olduğu konusunda açıklama ontolojinin tanıtımı kısmında yapılacaktır. Propertyler & Property kısıtları Property yaratımında genel olarak kavram haritasından faydalanılmıĢtır. Ancak kavram haritasındaki her property ve relation modellenmediği gibi, ihtiyaç durumunda yeni kavramlar da eklenmiĢtir. Property kısıtları mümkün mertebede az kullanılmaya çalıĢılmıĢ ancak yine de ontolojide anlamsal bir bütünlük sağlamasına özen gösterilmiĢtir.
instance girilmiĢtir. Bu verilerin TÜPRAġ bünyesindeki yazılımlar ile hiçbir bağlantısı bulunmamaktadır. Ontolojinin Tanıtımı GeliĢtirilen ontoloji TÜPRAġ RBT projesinin yazılım ayağının bir bölümünü kapsamakta olan bir baĢlangıç ontolojisidir. Birçok fikir ile beraber gelmekle beraber yalnızca limitli bir bölümü modellenmiĢtir. Ontolojinin geleceğine dair fikirler bir sonraki bölümde bulunabilir. Ontolojinin bir kopyası bu tez ile beraber verilen CD içerisinde bulunabilir. Bu kısmı incelerken bilgisayarda ontoloji açılması ve biryandan göz atılması anlamak konusunda oldukça yardımcı olacaktır. Ontolojideki sınıflar genellikle kavram haritasındaki sınıflardan oluĢmaktadır. LogicialThings içerisinde yer alan File sınıfının altında çeĢitli sınıflar bulunmaktadır. Bu sınıfların her birisi belirli dosya tiplerine ait dosyaları gösteren birer filtre olarak düĢünülebilir. Örneğin OfficeDocuments (belirlenmiĢ restrictionlara göre) sadece ontolojideki ofis belgelerini göstermektedir. MachineArchitecture makinenin mimarisini temsil eden sınıftır. Bu özellik istenirse data property olarak da ifade edilebilirdi ancak, ilerleyen süreçte bu özelliğin ontoloji kapsamında daha yoğun kullanılma olasılığı olduğundan içerisinde mimarilerin instance olarak yaratıldığı bir sınıf olması uygun görülmüĢtür. Software sınıfının içerisi kavram haritasına göre biraz kırpılmıĢtır. Bu özellikler ilerleyen dönemlerde ontolojiye ilave edilmelidir. Application sınıfı, TÜPRAġ içerisindeki bir bilgisayara kurulmuĢ olan bir yazılımı temsil etmektedir. Örnek olarak TUPRAS-12 isimli bir bilgisayara kurulu olan Microsoft Word programı ve TUPRAS-99PC isimli bilgisayara kurulu olan Microsoft Word programı birbirinden bağımsız iki ayrı kopyadır. Bu yüzden bu uygulamalara “fiziksel uygulama” adı verilmiĢtir.
CorelDraw bir uygulamadır. Web sitesi vardır, hakkında makaleler yazılmıĢtır, internetten bulunabilir. Ancak CorelDraw TÜPRAġ‟taki herhangi bir bilgisayarda bulunmuyorsa, sadece bir programdır, fiziksel olarak kurulu değildir. Bunlara “mantıksal uygulama” adı verilmiĢtir. Mantıksal uygulamaların ve iĢletim sistemlerinin birbirleriyle uyumluluk iliĢkileri compatibleWith ve incompatibleWith propertyleri ile belirlenmektedir. Böylelikle uygulamalar TÜPRAġ‟ta kullanılıyor olsun veya olmasın, bilgiler elde edildikçe bunlar xxxKB sınıflarına eklenebilmektedir. TÜPRAġ‟ta bir uygulamanın bir kopyası kurulduğunda, kurulu olduğu iĢletim sistemi bilgisi ile birlikte fiziksel uygulama instanceı oluĢturulur. Fiziksel uygulamanın hangi mantıksal uygulamanın bir gerçekleĢtirimi olduğu “insatanceOf” isimli property ile belirlenir. Fiziksel uygulamaların kurulu oldukları iĢletim sistemi (ve dolayısıyla bilgisayar) ve lisans durumu bilgileri tutulmaktadır. Fiziksel uygulamaların birbirleriyle uyumluluk durumları bağlı oldukları mantıksal uygulamalar aracılığı ile kontrol edilebilir. Normal Ģartlarda mantıksal uygulamaların birer class ve fiziksel uygulamaların bu classların birer instanceı olması normal karĢılanabilirdi. Ancak, mantıksal uygulamalar da fiziksel uygumalar kadar sık değiĢebilmektedir. (Her geçen gün yeni bir bilgi öğreniliyor, yeni bir uygulama çıkıyor.) Eğer mantıksal uygulamalar birer sınıf olsaydı yeni ekleme ve güncellemeler için, sürekli M1 seviyesindeki modelin değiĢtirilmesi gerekecekti. Modelin sık değiĢmemesi ve ekleme/düzenlemelerin instencelarda yapılması için mantıksal uygulamaların da M0 seviyesine indirilmesi uygun görülmüĢtür. Application‟daki mantığın aynısı iĢletim sistemi için de geçerlidir. Aynı zamanda uygulamalarda, mantıksal uygulamaların çeĢitli özelliklerine göre, kurulu olan uygulamaların tipleri de otomatik olarak çıkarsanabilmektedir. SetupMedia içerisinde TÜPRAġ bünyesinde kullanılan yazılımların ağa dağıtmak için kullanılan kurulum kopyaları temsil edilir. Definitive Master Version‟ların aynı zamanda birer dağıtım kopyası olarak da kullanılabilecekleri düĢünülerek tasarım buna göre yapılmıĢtır.
anlatılanları örnekleyecek individuallar ile donatılmıĢtır. Geliştirilen Ontoloji Hakkında Yorumlar, Ontolojinin Geleceği GeliĢtirilen ontoloji çok temel kavramları içermekte olup, bir baĢlangıç ontolojisi olarak düĢünülmelidir. Uygulama ve iĢletim sistemleri ile bu uygulama ve iĢletim sistemlerinin fiziksel kopyaları arasındaki iliĢkiler aynı ontolojide gösterilmiĢtir. Ancak, OperatingSystemKB ve ApplicationKB sınıfları yazılımlar ve uyumlulukları hakkında bilgi tutan çok geniĢ kavramlardır. Bu kavramların ikisi de birer ayrı ontolojide modellenmesi daha iyi olacaktır. Böylelikle hem bağımsız bir Ģekilde geliĢtirilebilir, hem de isim karıĢıklıkları farklı namespaceler sayesinde azalmıĢ olur. Ontolojide “lisans” konusuna yer verilmemiĢtir. Ancak lisans, bir anda lisans veya kira sözleĢmesi biten yazılımın sistemin çalıĢmasını etkileyebilmesi nedeniyle ontoloji kapsamına alınmalı veya kapsama alınmayacaksa bu nedeni ile birlikte raporlanmalıdır. Lisans yönetimi konusunda ontoloji geliĢtirebilmek için ITIL süreçlerinin incelenmesi ve çıktığında ISO/IEC 19770-3 standardının okunması uygun olabilir. Ontoloji ve kavram haritaları yazılımların “update” ve “upgrade” edilmesi ile ilgili hiçbir yapıtaĢı içermemektedir. Ancak sistemde yapılan değiĢikliklerin problemlere neden olabileceği düĢünülürse güncellemeler kök neden analizi için önemlidir. Güncellemeler ontoloji ve kavram haritasında modellenmelidir. Ontolojiyi besleyecek verilerin ve oluĢturulan ontolojilerin entegrasyonlarında kullanılabileceği için SKOS ve FOAF üzerlerinde rahatlıkla çalıĢılabilecek kadar ayrıntılı bir Ģekilde araĢtırılmalıdır. ġu anki ontolojide individuallar classlar ile aynı dosyada ve namespacede yer almaktadır. Ancak RBT projesi göz önüne alındığında çok ciddi derecede individual olacaktır. Bu yüzden model tek baĢına kalmalı, individuallar ayrı dosyalarda tutulmalıdır.
Microsoft Office) ile ilgili bir yönetim ve sınıflandırma yapılmamıĢtır. Yazılımları daha iyi yönetebilmek için bu iliĢkiler eklenebilir Uygulama, yazılım ailesi ve paket (Linux‟teki paket yönetimi) bazında gereksinim yönetimi eklenmelidir. incompatibleWith ve compatibleWith tek baĢına yeterli olmayacaktır. (Örnek: JDownloader dependedOn JAVA) Ontolojide Ģu an için, yazılımın kim/kimler tarafından kullanıldığı ve yazılım kullanma yetkileri ile ilgili bilgiler tutulmamaktadır. Ontolojinin SAM‟e daha yakın olması istenirse bu özellikler eklenmelidir. Ontolojide daha önceden oluĢmuĢ hataların kaydedilmesi ve bunların da çıkarsama sürecine dahil edilmesi uygun olabilir. ġu anki ontoloji basit düzeyde bir dosya yönetimi içermektedir. Ancak dosya yönetimi daha da geliĢtirilerek dosya bazında uyumluluk analizi ve yazılımın sağlık kontrolü için analizler yapılabilir.
19770 1-2 standartları çok detaylı bir Ģekilde incelenmiĢ, bunlardan esinlenerek kavram haritaları geliĢtirilmiĢ ve bu kavram haritaları ileride geliĢtirilmesi hedeflenen temel bir ontoloji tasarımı için kullanılmıĢtır. ITIL çok aĢırı detaylı bir standart olup, bu standardı öğrenmek ve uygulamak, birçok uzmanın görev almasını gerektiren ve yıllarca sürebilecek bir süreçtir. Bu standardı tamamen uygulamak çok ciddi bir maliyete neden olacaktır. Mecburi hale getirilmediği sürece (yasal zorunluluk vb.) bu standardın tamamının uygulanması yerine, standardın sadece gerekli olabilecek kısımlarının araĢtırılıp kısmi olarak uygulanmasının daha uygun olacağı düĢünülmektedir. SAM, projeye baĢlarken sahip olunan beklentilerin sadece bir kısmını karĢılayabilmiĢtir. ISO/IEC 19770-1 standardı yaratılacak ontolojideki bilgilerin her zaman güncel ve tutarlı kalabilmesi için yaratılması gereken kural ve prosedürler için temel alınabilecek bir standarttır. Software Identification Tag standardını kullanan uygulamaların maalesef çok azdır. Bu nedenle standardı uygulamak hem gereksiz, hem çok maliyetli olacaktır. Bunun yerine yazılım bilgilerinin yönetimi ve ontolojiye aktarımı için farklı yöntemler geliĢtirilebilir. SAM ile ilgili daha fazla yorum bölüm sonunda yer almaktadır. (bkz. Standartların RBT Varlıklarının Ontoloji Tabanlı İzlenmesi ve Yönetimi Projesinde Kullanımı Konusunda Yorumlar s.63) Kavram haritaları genel olarak oldukça kullanıĢlı olmuĢtur. Ancak olan eksikliklerin zaman içerisinde giderilmesi gerekmektedir. Örneğin kavram haritaları Ģu an için sanal makine yönetimi ile ilgili kavramlar sunmamaktadır. Ontoloji geliĢtirilirken kullanılan araç olan Protégé 3, maalesef arayüz olarak çok kullanıĢlı değildir. Ayrıca yazılımda bulunan hatalar ve zaman zaman çökmesi, reasoner çalıĢtırmamın kullanıĢlı olmayıĢı gibi sebepler ontoloji geliĢtirmeyi zorlaĢtırmıĢtır. GeliĢtirilen ontoloji, ontolojinin eksikleri, yapılması gerekenler ve öneriler ile ilgili ayrıntılı bilgi ontoloji kısmının bölüm sonunda yer almaktadır. (bkz. Geliştirilen Ontoloji Hakkında Yorumlar, Ontolojinin Geleceği s.95)
05 19, 2011, from IT Frameworks: http://www.itframeworks.org/wiki/Service_Catalogue_Manager IT Process Maps. (2010, 04 12). Availability Management - ITIL V2. Retrieved 05 19, 2011, from IT Process Maps: http://wiki.en.it- processmaps.com/index.php/Availability_Management_-_ITIL_V2 IT Process Maps. (2010, 10 09). Comparison between ITIL V3 and ITIL V2 - The Main Changes. Retrieved 05 19, 2011, from IT Process Maps: http://wiki.en.it- processmaps.com/index.php/Comparison_between_ITIL_V3_and_ITIL_V 2_-_The_Main_Changes IT Process Maps. (2010, 04 12). Financial Managament. Retrieved 05 19, 2011, from IT Process Maps: http://wiki.en.it- processmaps.com/index.php/Financial_Management IT Process Maps. (2010, 04 12). Problem Management - ITIL V2. Retrieved 05 18, 2011, from IT Process Maps: http://wiki.en.it- processmaps.com/index.php/Problem_Management_-_ITIL_V2 ITIL Central. (n.d.). A Short History of ITIL. Retrieved 05 17, 2011, from ITIL Central: http://itsm.fwtk.org/History.htm ITIL Frameworks. (2010, 03 02). Category:Strategy Generation Management. Retrieved 05 19, 2011, from ITIL Frameworks: http://www.itframeworks.org/wiki/Category:Strategy_Generation_Manage ment JSDAI. (tarih yok). 05 25, 2011 tarihinde JSDAI: http://www.jsdai.net/ adresinden alındı ManageEngine. (n.d.). ManageEngine AssetExplorer 5.6. Retrieved 05 23, 2011, from ManageEngine: http://www.manageengine.com/products/asset- explorer/cmdb-configuration-management-database.html Microsoft. (n.d.). 10 Reasons to Implement SAM. Retrieved 05 19, 2011, from Microsoft: http://www.microsoft.com/sam/en/us/reasons.aspx
Optimization Pack Yazılımların uyumluluk analizleri yapmayı, destek maliyetlerini düĢürmeyi ve varlık yönetimini sağlar. (Microsoft) AuditPro AuditPro Asset Management aĢağıdakileri sağlar: (AuditPro) Tanımlanan her ögeyi izleme yeteneği: Nerede kayıtlı olduğu vb. Sürekli güncel bir envanter veritabanı tutar. Aktif olarak kullanılan yazılım ve donanımların detaylı istatistikleri tutulur, yazılım ve donanımların hangi sıklıkta kimler tarafından kullanıldığını, ne kadar süre kullanıldığını detaylı olarak gösterir. Bağlı olunan networkteki yazılım ve donanımların detaylı olarak izlenip kontrol edilebilmesini sağlar. AssetExplorer AssetExplorer aĢağıdakileri sağlar: (ManageEngine) IT varlıkları ve IT-dıĢı varlıkların yönetimi, Software License Compliance (yazılım lisans uyumu) sağlar, Varlıkların kontratlarını ve maliyetlerini yönetir, Varlıkların tedariklerinden bertaraflarına kadarki yaĢam döngüsü boyunca idare edilmelerini sağlar. Asset Tracker AssetTracker‟ın özellikleri: (Alchemy Lab) Plugin ile geniĢletilebilme özelliğine sahiptir, Her türlü fiziksel varlığın yönetimi ve izlenmesi gerçekleĢtirilebilir, EriĢim kontrol sistemi içerir, Tüm varlıklar için yer imleri içerir ve tüm varlıkların belirli özelliklerine göre listelenebilmesini sağlar.
IT giderlerini kontrol etme, yetkisiz uygulamaları kontrol etme gibi özellikleri vardır. (Express Metrix) CDW Software Asset Management CDW Software Asset Manager‟ın özellikleri: (CDW) Bağlı olunan ağdaki tüm IP-adreslenebilir donanımları bulma özelliğine sahiptir, Organizasyondaki tüm IT varlıklarını görüntüleyebilme özelliğine sahiptir, Microsoft Windows, Linux, Unix, Apple OSX, AIX, Windows Mobil Smartphone‟lar ve PDA‟lerle uyumludur, Risk yönetimi mekanizması geliĢmiĢtir, IT bütçe kontrol mekanizması geliĢmiĢtir. IBM - Rational Asset Manager IBM Rational Asset Manager‟ın özellikleri: (IBM) Risk yönetimi, Bütçe kontrolü, Etki analizi, Yeniden kullanılabilir varlık tanımlamaları, GeliĢmiĢ raporlama özelliklerine sahiptir.
ubenzer
signer
kenjiro56
akiraasano
yosukemurata
aki_moon
uchinomasahiro
jscottmo
mariliarochas
matleenalaakso
satoryo56
.jpg){kind=avatar}
studio_graph
eileencodes
rasmusluckow
paulrobertlloyd
michaelherold
pedronauck
swwweet
bluesmoon
addyosmani
lara
denniskardys
bcantrill
philnash
