Yazılım Kalitesinin Değerlendirilmesi Ve Metrikler

Metrikler yazılımın ya da işlemlerin verilen özniteliklerin hangilerine sahip olduklarını gösteren nümerik ölçülerdir. Metriklere örnek olarak; “her bin satır koddaki hata sayısı”, “ortalama yazılım modülü boyutu”, verilebilir. Metrikler yazılım yaşam süreci boyunca toplanır ve analiz edilirler ve bize aşağıda verilen konularda yardımcı olurlar;

•  Yazılım kalite seviyesinin belirlenmesi
•  Proje zamanlama kestirimi(tahmin)
•  Zaman ilerlemesinin izlenmesi
•  Yazılım boyutu ve karmaşıklığının hesaplanması
•  Proje maliyetinin belirlenmesi
•  Süreçlerin iyileştirilmesi

 Yazılım kalite seviyesi ve proje maliyeti gibi amaçlar yeterince açıklanmadığı zaman, farklı yorumlara konu olabilir. Bu farklılıklar da karışıklığa ve çatışmaya sebep olabilirler. Örneğin, “uygulama çok nadiren çökmeli” şeklinde yapılan bir tanımlama yeterince belirli değildir. Burada “çok nadiren” kelimesini nasıl ölçeceksiniz? Bir günde bir mi?, hafta da bir mi? Ya da yılda bir mi?... Daha kesin bir amaç, “Uygulama yılda 3 defadan fazla çökmemelidir” şeklinde verilebilir. Bu şekilde belirtildikçe, amaç farklı yorumlara sebep olmaz ve daha ölçülebilir olur. Bir projeye görünürlük sağlamak için ölçülebilir, nesnel ölçütler olmadan projenin ilerlemesini ölçmek zordur; zamanında olup olmadığını, kalite hedeflerini karşılayıp karşılamadığını, müşteriye sevke hazır olup olmadığını… Ek olarak, “ölçemediğini geliştiremezsin”.

 Devamı olarak, bir organizasyonun süreçlerinin veya bir yazılımın geliştirilmesi, metriklerin toplanmasına ve nicel geliştirme amaçlarının belirlenmesine bağlıdır. Başarılı bir değerlendirme için, metrik toplama projenin başlangıcında başlamalı ve tüm yazılım yaşam döngüsü süresince, bakıma kadar devam etmelidir. Metriklerin toplanması ve analizi, önemli miktarda yönetimsel ve mühendislik çabası gerektirmektedir ancak ödemeler de buna değer durumdadır.

Kalite ise hangi yazılımın gereksinimlerini karşıladığının bir ölçüsü olduğundan dolayı, uyum derecesini ölçmemiz gerekmektedir. Yazılım kalite metriklerinin bir kümesini oluşturmakta yarar vardır. Bunlar proje için toplanan metrikler olup, tüm metriklerin bir alt kümesi olacaktır. Bu metrikler özel olarak yaşam döngüsü boyunca kullanılan yazılım kalite karakteristiklerine odaklanmışlardır.

Yazılım kalite metriklerinden en önemlileri aşağıda sıralandığı gibidir;

1.Hata yoğunluğu

Hata yoğunluğu, yazılımın boyutuyla ilişkili olarak hataların sayısını ifade eder. Boyut tipik olarak binlerce satır kod (KLOC) şeklinde ifade edilir, dolayısıyla hata yoğunluğu hatasayısı/KLOC olarak ifade edilebilecektir. Hatanın kullanıcı gereksinimlerinden herhangi bir sapma olduğunu hatırlayınız. Bu yüzden hata yoğunluğu kalite ölçümü için kullanılan en önemli metriklerden biridir. Genel olarak yüksek hata yoğunluğu, düşük kalite demektir. Şirketler tipik olarak hataları türüne göre ve şiddetine göre karakterize ederler ki göreceli olarak önemlerine göre ayırt edilebilsin. 

Aşağıdaki örnek yüksek şiddette bir hatanın nasıl tanımlanabileceğini ve kalite amacını tanımlamaktadır:

 Bir sınıf bir hata, yazılım gereksinim şartnamesinin üçüncü bölümüne göre memnuniyeti karşılamak için başarısızdır. Uygulama 5 sınıftan oluşabilmekte ve ilk ayda her 1000 kullanıcı için 1 hata raporundan başka işlem yapamamaktadır.

2.Sistem Güvenilirliği

Güvenilirlik sistemin uygunluğu ya da belirlenen bir peryotta sistem çökmesinin sıkılığıdır. Tipik olarak bu durum sistem çökmesi için ortalama zaman(MTTF) olarak kullanılır ve sistem çökmeleri arasındaki geçen zaman miktarıdır. MTTF emniyetle ilgili sıklıkla kullanılan bir metriktir(havayolu trafik kontrol sistemi, havacılık elektroniği ve silahlar).

Örneğin U.S hükumeti hava yolu trafik kontrol sistemini yıllık bazda üç saniyeden daha fazla erişilmez olmamasını görev kabul eder. Bir başka örnek hücresel ağlarda kullanılan iletişim anahtarlarında görülebilir. Büyük network sağlayıcılar, bu cihazların yılda %99.999 oranında erişilebilir olmasını görev sayar. Bu yılda 5 dakika 15 saniye kesinti anlamına gelmektedir. Okuyucu MTTF için neden %100 değil diye sorabilir. Cevap genel olarak bu oranın elde edilebilir olmadığıdır.

3.Müşteri problemleri

Müşteri problemleri, müşterinin ürünü kullanırken aldığı tüm problemlerin sayısıdır. Problemlerden bazıları yazılımdaki geçerli hatalardan kaynaklanabilir. Diğer bazıları hata kaynaklı olmayabilir, kafa karıştırıcı kullanıcı ara yüzü, zayıf hazırlanmış dökümantasyon veya hataları çoğaltmak(yinelenen)(çoktan rapor edilmiş ve çözülmüş ama raporlama biriminin bilmediği hata) gibi sebeplerden dolayı olabilir. Yinelenen hatalar bir hatanın ne kadar yaygın olduğunun en iyi göstergesi olabilir. 

Bunlar farklı kullanıcılar tarafından karşılaşılan aynı hatalardır. Tüm bu durumlarda, problem bir hatadan kaynaklı olsun veya olmasın, müşteriler kullanışlılık problemi olarak algılanan sorunlarla karşılaşıyorlar ve sonuç olarak yazılımdan memnun olmuyorlar. Bu da müşteri problemlerini en önemli kalite göstergesi yapmaktadır. Bu metrik tipik olarak problem/kullanıcı/aylar ile ifade edilir. Bu ve diğer metrikler yazılım ürünü teslim edildikten sonra bölüm 7 de tartışıldığı gibi test ve bakım aşamasında toplanabilir.

3.Uyumluluk (Cohesion) 

Bunge benzerliği σ(), iki varlık arasındaki özellik kümesinin kesişimi olarak adlandırılmaktadır. Benzerliğin bu genel tanımından yola çıkarak metotlar arasındaki benzerliğin derecesi, bu iki metot tarafından kullanılan nitelik değişkenleri kümesinin kesişimi olarak tanımlanmaktadır. Elbette metodun kullandığı nitelik değişkenleri metodun özellikleri değildir ama nesnenin metotları, kullandığı nitelik değişkenlerine oldukça bağlıdır.σ(M1,M2), M1 ve M2 metotlarının benzerliği, {Ii} = Mi metodu tarafından kullanılan nitelik değişkenleri olmak üzere σ(M1,M2) = {I1} n {I2}’dir.Metotların benzerlik derecesi, hem geleneksel yazılım mühendisliğindeki uyumluluk kavramı ile hem de kapsülleme ile ilişkilidir.

Metotların benzerlik derecesi, nesne sınıfının uyumluluğunun başlıca göstergesi olarak kabul görülebilir. Uyumluluk bir sınıftaki metot ve niteliklerin birbirleriyle ilgili olmasının ölçüsüdür. Bir sınıftaki metot parametrelerindeki ve nitelik tiplerindeki güçlü örtüşme iyi uyumluluğun göstergesidir. Eğer bir sınıf aynı nitelik değişkenleri kümesi üzerinde farklı işlemler yapan farklı metotlara sahipse, uyumlu bir sınıftır. Eğer bir sınıf birbiri ile ilgili olmayan işler yapıyorsa, birbirleriyle ilgili olmayan nitelik değişkenleri barındırıyorsa veya çok fazla iş yapıyorsa sınıfın uyumluluğu düşüktür.

4.İşlevsellik

Yazılımın ihtiyaçları karşılama becerisi olarak tanımlanmaktadır. Uygunluk, doğruluk, birlikte çalışılabilirlik ve güvenlik konuları bu sınıf altında incelenmektedir.

5.Karmaşıklık (Complexity) 

Karmaşıklık, sınıfların iç ve dış yapısını, sınıflar arası ilişkileri kavramadaki zorluğun derecesidir. “Bir nesnenin karmaşıklığı bileşiminin çokluğudur. Buna göre karmaşık bir nesne çok özelliğe sahip olur. Tanımdan hareketle (x, p(x)) nesnesinin karmaşıklığı özellik kümesinin kardinalitesi yani |p(x)| olur.

6. Code Coverage

Yazılan testlerin kodun ne kadarını kapsadığını ölçer. Code Coverage için %80 gibi bir oran oldukça iyi gibi görünse de aslında az sayıda basit test yazarak dahi bu orana ulaşılabilmesi bir hayli kolaydır. Bu sebepten Code Coverage oranının %100 olması beklenmektedir.

7.Güvenilirlik

Yazılımın düzgün çalışma halini muhafaza edebilme becerisi olarak tanımlanmaktadır. Olgunluk, hata toleransı ve geri kurtarma konuları bu sınıf altında incelenmektedir.

8.Kullanılabilirlik

Yazılımın kullanım kolaylığı sağlayan yetenekleri olarak tanımlanmaktadır. Öğrenebilme, anlaşılabilirlik, işletilebilirlik ve kullanıcı etkileşimi konuları bu sınıf altında incelenmektedir.

  

9.Verimlilik

Yazılımın ihtiyaç duyulan ölçüde yeterli performansla çalışabilme becerisi olarak tanımlanmaktadır. Zaman ve kaynak kullanımı konuları bu sınıf altında incelenmektedir.

10.Bakılabilirlik

Yazılımın değişiklik veya düzeltme isteklerine adaptasyon yeteneği olarak tanımlanmaktadır. Değiştirilebilirlik, test edilebilirlik, analiz edilebilirlik ve bağışıklık konuları bu sınıf altında incelenmektedir.

11.Taşınabilirlik

Yazılımın çalıştığı ortam değişikliklerine uyum sağlayabilme yeteneği olarak tanımlanmaktadır. Adaptasyon yeteneği, yüklenebilirlik özellikleri, ortam değiştirme imkânı ve diğer yazılımlarla uyum konuları bu sınıf altında incelenmektedir.

12. Müşteri Memnuniyeti

Müşteri memnuniyeti metrikleri yaygın olarak müşteri memnuniyeti anketleri sayesinde toplanırlar. Cisco System gibi şirketler [5] müşterilerinden memnuniyet ölçüsü olarak 5 üzerinden bir geri besleme alırlar (5=çok memnun, 1=çok memnuniyetsiz).

IBM CUPRIMDSO kategorilerini kullanır (Yetenek/fonksiyonellik, kolay kullanım, başarım, güvenilirlik, bakım kolaylığı, yüklenebilirlik, dökümantasyon, servis, ayrıntılı tasarım). Hewlett-Packard FURPS(Fonksiyonellik, Kolay kullanım, güvenilirlik, başarım ve servis) metriğini kullanır [4]. Bu anketlerin sonucu ilgili şirketlerin kendi önceliklerini geliştirmeleri için yönlendirici olarak kullanılır.

13.Nesne Sınıfları Arasındaki Bağımlılık (Coupling Between Object Classes – CBO)

Sınıfın bağımlı olduğu sınıf sayısıdır. Bu metrikte, bir sınıf içinde nitelik ya da metotlar diğer bir sınıfta kullanılıyorsa, iki sınıf arasında bağımlılık olduğu kabul edilmiştir. Sınıflar arasındaki aşırı bağımlılık modüler tasarıma zarar verir ve tekrar kullanılabilirliği azaltır. Bir sınıf ne kadar bağımsızsa başka uygulamalarda o kadar kolaylıkla yeniden kullanılabilir. Bağımlılıktaki artış, değişime duyarlılığı arttıracağından, yazılımın bakımını zorlaştırır. Bağımlılık aynı zamanda tasarımın farklı parçalarının ne kadar karmaşık test edileceği hakkında fikir verir. Bağımlılık fazla ise testlerin daha özenli yapılması gerektiğinden test maliyetleri artacaktır.

14.Sınıfın Ağırlıklı Metot Sayısı (Weighted Methods per Class – WMC)

Bir sınıfın tüm metotlarının karmaşıklığının toplamıdır. Tüm metotların karmaşıklığı 1 kabul edilirse, sınıfın metot sayısı olur. Sınıfın metotlarının sayısı ve metotlarının karmaşıklığı, sınıfın geliştirilmesine ve bakımına ne kadar zaman harcanacağı hakkında fikir verebilir. Metot sayısı çok olan taban sınıflar, çocuk düğümlerde daha çok etki bırakırlar; çünkü tanımlanan tüm metotlar türetilen sınıflarda da yer alacaktır. Metot sayısı çok olan sınıfların uygulamaya özgü olma ihtimali yüksektir. Bu nedenle tekrar kullanılabilirliği düşürürler.

15.Metotların Uyumluluğu (Lack of Cohesion in Methods – LCOM)

Bu metriğin birden çok tanımı olmakla birlikte ilk kez kullanılanı şu şekildedir: C1 sınıfının M1, M2, …, Mn metotları olduğunu ve {li} kümesinin de Mi metodunda kullanılan nitelik değişkenleri kümesi olduğunu kabul edelim. Bu durumda LCOM bu n kümenin kesişiminden oluşan ayrık kümelerin sayısıdır. Daha sonra bu tanım yenilenerek şu şekle getirilmiştir: P hiçbir ortak nitelik değişkeni paylaşmayan metot çiftlerinin kümesi, Q en az bir ortak nitelik değişkeni paylaşan metot çiftlerinin kümesi olsun. Bu durumda LCOM, |P| > |Q| ise |P|-|Q|, aksi halde 0 olur. Bunlarla birlikte literatürde farklı tanımlar da mevcuttur. Sınıfın uyumluluğunun düşük olması, sınıfın iki veya daha fazla alt parçaya bölünmesi gerektiğini gösterir. Düşük uyumluluk karmaşıklığı arttırır, bu nedenle geliştirme aşamasında hata yapma ihtimali yükselir. Ayrıca metotlar arasındaki ilişkisizliklerin ölçüsü sınıfların tasarımındaki kusurların belirlenmesinde de yardımcı olur.

16.Specialization Index (SIX)

Kod karmaşıklığını ve bakım maliyetlerini arttırmasından dolayı overload edilmiş fonksiyon sayısının mümkün olduğunca az olması istenir.

Bundan dolayı SIX = (Overload Edilmiş

Metot Sayısı * DIT) / NOM şeklinde

hesaplanır. 1.2 (veya %120)'ye kadar

normal kabul edilir.

Nesne Yönelimli Metrikler

Alt Sınıf Sayısı ( Number of Children - NOC)

NOC metriği sınıftan türemiş alt sınıflarının sayısını verir.

• Alt sınıf sayısı çoğaldıkça kalıtım özelliğine bağlı olarak yeniden kullanımın arttığı anlaşılır.
•  
• ·Alt sınıf sayısının çokluğu sınıfın hatalı soyutlama yapıldığını , belki de hatalı bir hiyerarşi kurulduğunu gösterebilir.
• NOC sınıfın nüfus alanı hakkında bir fikir verir.NOC metriği yüksek sınıflar gözden geçirme , test gibi süreçlerin daha dikkatli ve uzun tutulması gereken yerlerdir.

17.Kod Büyüklüğü (Lines Of Code LOC)

Geleneksel olarak yazılımın boyutu satır

sayısı ile ölçülür. Satır büyüklüğü çeşitli şekillerde ölçülür :Satır Sayısı ( Lines Of Code – LOC ) ölçümü programın tüm satırlarının sayılmasıdır.

Yorum ve boşluk içermeyen (Non-comment Non-blank NCNB veya Source Lines Of Code SLOC ) programın yorum satırları ve boş satırlardan arındırılmış halidir.

Çalıştırılabilir yordam sayısı (Executable Statements EXEC) program içinde yer alan yordam sayısıdır.

Yorum Oranı (Comment Percentage - CP)

Yorum oranı (Comment Percentage CP) programın için hazırlanmış yorum satırlarının (kod ile birlikte ya da dışarıda) , toplam programın yorum ve boşluk içermeyen satır sayısına (SLOC) bölümü ile bulunur.Yüksek yorum oranı programların anlaşılabiliğini arttıran ve bakımını kolaylaştıran bir faktördür. Yorum oranının %20 ila %30 arası olması tavsiye edilen bir durumdur.

Kaynaklar

1. U. Erdemir, U.Tekin, F.Buzluca, “Nesneye Dayalı Yazılım Metrikleri ve Yazılım Kalitesi” Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu (YKGS08), İstanbul, 2008.

2. Doç Dr. Feza Buzluca, İTÜ, BLG468E Object-Oriented Modeling and Design ders notları  http://ninova.itu.edu.tr/tr/dersler/bilgisayar-bilisim-fakultesi/2097/blg-468e/ekkaynaklar/

ITIL (Information Technology Infrastructure Library)

ITIL (Bilgi Teknolojileri Alt Yapı Kütüphanesi ) ; doğru servislerin, doğru müşterilere, müşteri ihtiyaçları göz önüne alınarak tasarlanması, minimum risk ile hayata geçirilmesi ve mümkün olduğu kadar yüksek verimlilikle çalıştırılması esaslarına dayanan, tüm bu şartlar sağlandıktan sonra ise servislerin sürekli olarak iyileştirilmesini öngören endüstriyel bir “best practice” kütüphanesidir. Ancak su anda kütüphane olmaktan çıkıp BT yönetim metodoloji olmuştur , çünkü ITIL’ı uygulayan firmalar BT servislerinde gözle görülür bir iyileşme elde etmişlerdir.Genelde bu iyileşmeler hizmet seviyesi kalitesinin yükselmesi, erişebiliriliğin artması , doğru kapasite planlamasının yapılarak maliyetlerin kontrol altına alınması gibidir. 

ITIL  bize servislerimiz ile ilgili yapılması gerekenleri doğrudan göstermez; bunun nedeni her işletmenin farklı servislere, her servisin ise farklı süreçlere ihtiyaç duymasıdır. Ancak genel olarak servis mimarisini ve bu mimarinin oluşturulması veya iyileştirilmesi için takip edilmesi gereken yolları gösterir.

ITIL’ın genel olarak amaç ve faydalarını aşağıdaki şekilde sıralayabiliriz.

§  Maliyetleri Düşürmek

§  Erişilebilirliği Arttırmak

§  Kapasiteyi Ayarlamak

§  İş Gücünü Arttırmak

§  Kaynakların Verimli Kullanılmasını Sağlamak

§  Ölçülebilirliği Artırmak

§  Yüksek Kalitede BT Hizmeti

ITIL Tarihçesi ve Versiyonları

1980’li yıllarda İngiltere’de, dönemim Başbakanı Margaret Thatcher tarafından talep edilmesiyle çalışmalara başlanmıştır.İlk çıkış amacı İngiliz hükümetinin BT hizmetlerinin kalitesini artırmak idi ve 3 versiyon halinde yayınlanmıştır.(1985-2001-2007)

  

ITIL v1 1985’de yayımlanmış olup elimizde pek fazla bilgi bulunmamaktadır.

ITIL v2 2001 yılında 8 kitap olarak yayınlanmıştır. Daha çok servis disiplini felsefesi mantığı ile çalışmaktadır.

ITIL v3 2007 yılında yayınlanmış olup , bir önceki versiyona göre modüler yapıdan yaşam döngüsü yapısına geçilmiştir.Yani bir servisin planlama aşamasından , sona erdirilmesine kadar olan tüm süreci kapsamaktadır.

 Hizmet Yönetimi uygulamaları olarak bilinen ITIL v3 temel olarak birbiri ile bağlantılı 5   faz’dan oluşmaktadır; 

·       Service Strategy

·       Service Design

·       Service Transition

·       Service Operation

·       Continual Service Improvement

ITIL mimarsi birbiri ile grift bir ilişiki içerisinde yer alıyor. Bir BT Organizasyonu içerisindeki BT stratejilerinin belirlenerek tasarımının yapılması sonrasında servis geçiş süreçlerinin tanımlanması ve operayon süreçlerinin tanımlanması ile servis yaşam döngüsünün büyük bir kısmını tamamlamış oluyoruz. En son fazda ise Servis kalitesinin artırılabilmesi için gereken raporlama, ölçümleme ve iyileştirme işlemlerinin yapılacağı süreçlerin diğer süreçler ile entegre edilmesi ile süreç haritamızı tamamlamış oluyoruz.

Süreçlerin tasarlanabilmesi, uygulanabilmesi,entegre edilebilmesi ve yönetilebilmesi noktasında birtakım ana roller’e ihtiyaç duyulmuş ve ilgili roller tanımlanmıştır. Bu roller organizasyon süreçlerinin analiz edilmesinden sonra deploy edilmelidir. Kısaca bu görevlere bakacak olursak;

•           Service Owner : Bir servisin tasarımı, entegrasyonu, performansı, iyileştirilmesi ve yönetilmesini kapsar.
•           Process Owner : Bir servisin tasarımı, entegrasyonu, performansı, iyileştirilmesi ve yönetilmesini kapsar.
•           Product  Manager : İlgili servis gruplarının performansı, iyileştirilmesi ve    yönetilmesini kapsar.
•           Service Manager  : Oluşum içerisinde yer alan tüm servislerin performansı, iyileştirilmesi ve yönetilmesini kapsar.

    1.Service Strategy

Sadece IT için değil bütün işlerde önemli olan işin tamamını kuş bakışı net olarak görebilmektir. IT servis yönetiminde alınan karaların nasıl icra edildiği önemli bir konudur. Servis Strateji, Servis Yaşam Döngüsü içerisinde bulunan Service Tasarım,  Servis Geçişi,  Servis Operasyon ve Devamlı Servis Geliştirme (CSI)  aşamaları için önemli yer teşkil eder.

Sürecin Amacı: Bir organizasyonun uzun vadeli gelişiminin başarılı bir şeklide sağlanabilmesini ve servis sağlayıcılara stratejik düşünme kabiliyetini oluşturmasını amaçlar. Servis Stratejisi, IT’nin organizasyona karşı bakış açısını ayarlamasına yardımcı olur. Bu sayede IT, müşterisine daha başarılı hizmetler sunacaktır. Hizmete fayda ve garanti açısından bakarak tanımlarsak, işe yarar bir servisin amaca ulaşmadaki kabiliyeti daha fazladır. Aynı zamanda belirli kısıtların ortadan kalması da müşteri açısından daha performanslı sonuçlar yaratacaktır.

Service Strateji, ITIL çatısı için kapsamlı bir vizyon sağlar. ITIL kullanan organizasyonlar, Servis Strateji evresini stratejik bakış açısı kazanmak için kullanabilirler. Ayrıca bu evre müşteriyi ve pazar tabanlı hedefleri ve beklentileri anlamak için yardım edececektir. Servis Strateji evresi, maliyetleri ve riskleri yönetmek için organizasyonun donanımlı olup olmadığına emin olmamıza da yardımcı olacaktır.

Servis Strateji Evresi

·       Pazarı tanımlamak

·       Önerileri Geliştirmek

·       Stratejik Kazançları, malvarlıklarını geliştirmek

·       Uygulama için hazırlamak

·       Müşteriyi anlamak

·       Fırsatları anlamak

·       Hizmetlerin sınıflandırılması ve tahayyülü/görsellenmesi( göz önünde canlandırmak)

Stratejinin 4P Kuralı

Aşağıdaki 4P, hizmet stratejisinin farklı formlarını tanımlar ve servis stratejisine giriş noktaları olarak kabul edilirler.

Perspective

Bir vizyon ve istikameti tanımlar ve müşteriyle etkileşimin iş felsefesini ifade eder.

Positions

İyi tanımlanmış bir tutum benimsemeye karar vermeyi tanımlar.Müşterilerin zihnindeki ayırt edicilik olarak ifade edilir.Diğerleri gibi aynı alanda rekabet anlamına gelir ancak müşteriye cazip gelen farklılaştırılmış bir değer önerisiyle bunu yapar.

Plan

Bir plan “Nasıl yüksek değer ya da düşük maliyetli hizmet sunarız? “ ya da “Özelleştirilmiş hizmetlerimizi nasıl sağlar ve sunarız? “ sorularının cevabını verir.

Pattern

Bir kuruluşun yaptığı şeylerin temel yolunu tanımlar.

Hizmet Stratejisi Süreçleri

Aşağıdaki şemada farklı süreçler ve onların hizmet stratejisindeki ilişkisi ifade edilmektedir:

Strategy Management

Bu süreç dört faaliyeti içerir: Pazar tanımı, arzın geliştirilmesi, stratejik varlıkların geliştirilmesi ve stratejinin uygulanması için hazırlık.

Service Portfolio Management

Hizmet portföyü, hizmet sağlayıcının sağlayabileceği tüm hizmetleri tanımlar.Bir kuruluş genelinde hizmet yönetimi yatırımlarını kontrol etmeye ve aktif olarak değerini yönetmeye yardımcı olur.

Business Relationship Management

Bu süreç, müşterilerin ihtiyaçlarını karşılamak için uygun hizmetlerin geliştirilmesini sağlayarak hizmet sağlayıcı ve müşteriler arasında iyi bir ilişki kurulmasıyla ilgilenir.

Demand Management

Bu süreç hizmetlerin arz ve talebi arasındaki dengeyi korur.

    2. Service Design (Hizmet Tasarımı)

Bu aşamada ise oluşturulacak olan hizmetin çeşitli kısıtlara karşı olan tasarımı ile ilgilenmektedir. Ayrıca iş birimlerinin ihtiyaçlarına yönelik olan hizmetlerin ne şekilde tasarlanacağını, hizmetlerin finansal değerlendirmesini ve ileri dönük olarak desteklenip desteklenemeyeceğini belirler. Bu aşamanın en önemli çıktısı olarak Hizmet Tasarım Paketleri (Service Design Package – SDP) elde edilir. Bu paketler içerisinde hizmetin geliştirilmesi, test edilmesi, yaygınlaştırılması ve operasyonu ile ilgili tüm detaylar yer almaktadır.

Hizmet Tasarımı başlığında incelenen alt süreçler şunlardır:

Service Catalog Management (Hizmet Katalog Yönetimi): Halen kullanılmakta olan hizmetlerle ilgili bilgilerin herkes tarafından erişilebilir olmasını sağlar.

Supplier Managemet (Tedarikçi Yönetimi): Tedarikçilerin ve anlaşmaların yönetimi ile buraya harcanan fonun karşılığı olan değerin alınıp alınmadığını kontrol etmektedir.

Service Level Management (Hizmet Seviye Yönetimi): İş birimleri ile yakın çalışarak işletmenin ihtiyaçlarının servis sağlayıcı tarafından net bir şekilde anlaşıldığını ve servis sağlayıcının bu ihtiyaçları yanıtlayabilecek kapasitede olduğunun kontrolünü sağlar.

Availability Management (Erişilebilirlik Yönetimi): Sunulacak hizmetlere uygun olan erişilebilirlik koşullarını tasarlamanın yanında erişilebilirlik ile ilgili testleri gerçekleştirir.

Capacity Management (Kapasite Yönetimi): Hizmet yaşam döngüsüne birebir bağlı olarak çalışmaktadır ancak bu çalışmalarını kapasite perspektifinden gerçekleştirmektedir.

IT Service Continuity Management (IT Hizmet Sürekliliği Yönetimi): İş sürekliliği planı doğrultusunda çalışarak işletmeye uygun IT teknik ve servis bileşenlerinin işletme tarafından belirlenen süreler içerisinde olası bir hatadan geri döndürülmesini sağlar ve kontrolünü gerçekleştirir.

Information Security Management (Bilgi Güvenliği Yönetimi): Veri ve bilgi güvenliğinin sağlanması ve bunun takibi ile ilgilenen süreçtir.

Roller ve Sorumluluklar;

·        Service Design Manager : Hizmetler ve süreçler noktasında oluşturulan tasarım ve genel koordinasyon dan sorumludur.

·        IT Designer /Mimar : Planlama, tasarım, strateji, mimari, tasarım için gereken teknolojiler ve genel koordinasyondan sorumludur.

·        Service Catalogue Manager: Doğru bir Hizmet kataloğunun oluşması noktasındaki üretim, geliştirme ve bakımdan sorumludur.

·        Service Level Manager : Hizmet Seviyesi kalitesinin karşılanabilmesi ve kabul edilebilir olmasından sorumludur.

·        Availability Manager : Tüm Servislerin kabul edilebilir hedeflerine ulaşmasından sorumludur.

·        IT Service Continuity Manager : İş ihtiyaçları, gereklilikleri ve zaman çizelgelerine uygun olarak tüm servislerin iyileştirilmesinden sorumludur.

·        Capacity Manager : BT Kapasitesinin bügünkü ve gelecekteki iş talepleri ile uyumlu olmasından sorumludur.

·        Security Manager : Belirlenmiş iş güvenliği politika riskleri, etkileri ve gereksinimleri ile BT güvenliğinin uyumlu olmasından sorumludur.

·        Supplier Manager : BT Tedarikçileri,sözleşmeleri ve anlaşmaların iş ihtiyaçlarına uyumlu olması ve değerinden sorumludur.

         3.Service Transition 

Hizmet geçiş rolü, Operasyonel süreçte kullanılmak üzere iş gerekliliklerini iletir.

Hizmet geçişi, Servis tasarım aşamasından Hizmet tasarım paketini alması ile başlar ve Operasyonel aşamaya devam eden operasyon ve hizmet desteği için gerekli tüm bilgileri ve elemanaları teslim eder.

İş Koşulları, gereksinimleri yada varsayımlar tasarım sürecinden sonra değişime uğradıysa, Hizmet geçiş aşamasında gerekli hizmeti sunmak için bir takım değişiklikler gerekebilir. Unutulmaması gereken en önemli nokta Hizmet Geçişi sadece uygulamalarla ve/veya normal şartlar altında nasıl kullanıldığı ile değil hizmetlerin tüm yönleri ile uygulanmasından sorumludur.

Süreç içerisinde bilinmesi gereken V-Model yapısını ve RFC,CI,CMS,CAB,ECAB gibi tanımları ve içeriği hakkındaki detayları, süreci daha derin incelediğimiz makalenin içinde bulabilirsiniz.

Süreçler;

·        Change Management : Değişiklik Yönetimi, ilgili değişikliklerin değerlendirilmesi, kayıt edilmesi, önceliklendirilmesi, planlanması, test edilmesi, uygulanması, dökümante edilmesi ve düzenli şekilde gözden geçirilmesini sağlar.

Bir Hizmet değişikliği, ek, yetki , planlama yada desteklenen hizmet yada hizmet bileşeni gibi üzerinde olabilecek değişiklik ve ilgili dökümanlarla ilişkilendirilmesidir.

·        Service Asset and Configuration Management (SACM) : Bir Organizasyonun altyapısını oluşturan ilişkileri, tüm varlıkların kontrolünü ve bilgilerin doğruluğunu sağlar. Yapılandırma öğeleri (Configuration Item(CI)) ve hizmet varlıkları’nın belirlenmesi, kontrol edilmesi ve hesaplanması ile birlikte Servis yaşam döngüsü boyunca kendi bütünlüğünü sağlamayı ve korumayı amaç edinir.

·        Knowledge Management : Bilgi Yönetimi, işin gerektirdiği hizmet desteğini, doğru kişiye doğru bilgi ile doğru zamanda iletmekten sorumludur.

Roller ve Sorumluluklar;

Bir Organizasyon içerisinde hizmete geçiş sunan personel; etkin, verimli ve va olan çeşitli seçenekleri sunmak için organize edilmelidir.

Tipik bir organizasyon içerisinde bu roller tahmin ile değil ayrı bir grup olarak düşünülür. Bu Daha fazla beceriye ve deneyime sahip Aynı insanlar Birden fazla yaşam döngüsü aşamalarına dahil olabilir anlamına gelir.

         4.Service Operation (Hizmet Operasyon)

Hizmet Operasyonu, Kullanıcılarına ve Müşterilerine belirlenmiş hizmet seviyesini sağlayacak olan uygulama yönetimi, teknoloji ve altyapı hizmet desteği sunar.

Bu hizmetler sadece servis yaşam döngüsünün bu aşamasında işe gerçek değerini verir. Hizmet yaşam döngüsü, Hizmet operasyonu aşamasında, kabul edilen parametreler dahilinde faaliyet sağlamakla ilgilenir. Herhangi bir hizmet kesintisi meydana geldiğinde, Servis operasyonu olabildiğince çabuk şekilde servisleri geri yüklüyerek iş etkisini en aza indirgiyor.

Bu sürecin fokus olduğu birtakım parametreler olan “Reactive-Proactive”, “Internal-External”, “Cost-Quality”, “Stability- Flexibility” arasında denge sağlamak durumundadır. Eğer bu dengeyi kuramazsa Hizmet Operasyonu kötü olarak görünüyor olucaktır.

En önemli kısımlardan biri ise operasyon esnasında olan iletişim dir ver her ne olursa olsun iletişimin doğru algılanması kurulması gerekir. Bu ilişkiler;

·        BT Hizmet sağlayıcı ile kullanıcı arasındaki iletişim..

·        BT Hizmet sağlayıcı ile Müşteri arasındaki iletişim..

·        BT Hizmet sağlayıcı içerisinde yer alan farklı süreçler, fonksiyonlar ve takımlar arasındaki iletişim..

·        BT Hizmet sağlayıcı ile tedarikçileri arasındaki iletişim..

Süreçler;

·        Incident Management : Sorun Yönetimi, olası herhangi bir sorunun bildirilmesi ile gelen isteğin işe etkisinin en aza indirgenmesi noktasında Çoğunlukla servislerin hızlı şekilde restorasyonu sağlar. Fakat bazı vakalardan durum sorun yönetiminden çıkarak yardım masası tarafından sahiplenilir ve uygulanır.

Temel aktiviteler;

·        Detection

·        Logging

·        Classification

·        Prioritization

·        Investigation and Initial Diagnosis

·        Escalation

·        Resolution and Recovery

·        Closure

·        Problem Management : Problem yönetimi,Vaka’ya sebep olan oluşumun içerisindeki hata yada kusuru düzeltmek ve tanımlamak ile ilgilenir. Sorunların azalmasına ve engellenmesini yardımcı olur ve iki alt süreçten oluşur;

·        Reactive Problem Management : Genellikle Sorun yönetimi süreci tarafından yönlendirilen problemlerin aşılması sürecidir.

·        Proactive Problem Management : Hata-Sorun isteği gelmeden önce servisler ve altyapı üzerinde Proaktif olarak iyileştirme aramaları yapan süreçtir.

·        Event Management : Olay Yönetimi, Altyapı üzerinde oluşan olayların tespiti ve uygun müdahale eylemlerinin seçimi ile ilgilenir. Olayların erken tespit ediliyor olması, etkilenen kullanıcılar tarafından gelecek hata sayılarının düşmesine neden olacağı gibi, Sorun yönetimi sürecinin performansını artırarak olayların azalıtması sağlanmış olur. 3 Tip olay vardır;

·        Informational

·        Warning

·        Exception

·         Access Management : Erişim Yönetimi kimlik ve haklar ile ilgilenir. Bu süreç kimlik ve yetki doğrulama, hizmetlere erişim verme, işlem günlüğü, erişim izleme-kaldırma yada durum veya rollerin haklarını değiştirmeyi içerir.

Erişim Yönetimi, gizlilik, kullanılabilirlik ve veri bütünlüğünü yönetmenize yardımcı olur. Yetkili olmayan kullanıcıların erişimlerini engellerken, erişim yetkisi olan kullanıcıların bir servise yada servis grubuna erişimini sağlar.

·        Service Request Fulfillment : Hata yönetimine ddahil edilemiyecek ortak kullanıcı istekleri olarak adlandırılmaktadır. Yeni bir ekipman yada bir eğitim isteği bu başlığın altında değerlendirilir. Özellikle belirli periyotlarda kullanıcılar tarafından yapılmakta olan bir isteğin cevaplandırılması için idealdir.

Bütün istekler kayıt edilmeli ve izlenilmelidir. Bu süreç içerisinde aynı zamanda dikkat edilmesi gereken en önemli konu ise isteğin cevaplanmadan önce onay sürecine sokulmasıdır.

           ·     Continual Service Improvement (Hizmet İyileştirme Sürekliliği)

Değişen iş ihtiyaçlarına göre fonksiyonların, süreçlerin ve hizmetlerin yeniden uyumlu hale getirilmesi sürecidir. Aynı zamanda Genel Hizmet yönetimi içerisindeki kalite yönetim yöntemleri uygulama tutarlığı ile ilgilenir.

ITIL içerisinde “Ölçü (Measurement)” kritik bir rol almaktadır. Hizmet iyileştirme sürekliliğinin bir parçası, aynı zamanda Hizmet seviyesi Yönetiminin ve tüm süreçlerin önemli bir parçasıdır. Ölçümleri burada 4 temel amaç için kullanılabilir;

·        Doğrulamak (Justify)

·        Direkt (Direct)

·        Müdahale (Intervenne)

·        Onaylamak (Validate)

(Bir sonraki makalemiz içerisinde metodlarından bahesediyor ve ölçümlemedeki kritik noktalardan bahsediyor olacağız.)

7 adımda iyileştirme süreci ölçümleme ile Hizmet performansının düzeltilmesi ve iyileştirilmesini sağlıyor. İsterseniz kısaca bu adımların ne olduğuna bakıyor olalım;

·        Karar Ne Ölçülmelidir

·        Karar Ne Ölçülebilir

·        Veri Toplama

·        Veri İşleme

·        Veri Analizi

·        Veri Kullanma ve sunma

·        Düzeltici Eylem (Aksiyon) uygulama

Hizmet Seviyesi Yönetimi (SLM) aynı zamanda Servis Tasarım yaşam döngüsü aşamasının içerisindeki süreçlerden birisidir. Bir çok aktivite ve nesne Hizmet iyileştirme sürekliliği ile ortaktır. Özellikle her iki Hizmet seviyesi yönetimi ve iyileştirme sürekliliği düzenli ölçüm, servislerin gözden geçirilmesini ve servis yönetim başarımının diğer yönlerini vurgulamaktadır.

5- Continual Service Improvement (Sürekli Servis İyileştirmesi):

 Sürekli Servis İyileştirmesi, diğer tüm yaşam döngüsü adımlarına entegre olan bir adımdır. Bu aşamanın en önemli özelliği devamlı olarak bir gelişim ve değişimi desteklemesidir.  

Bu aşamadaki çalışmalardan biri, Hizmet operasyonu bölümünden gelen sistemin çalışma performans verilerine bakarak hizmetler üzerinde yapılabilecek olan her türlü  değişiklik Hizmet Stratejisi aşamasında kullanılmak üzere Service Improvement Plan (Hizmet Geliştirme Planı) olarak dökümante edilmektedir.

Kaynaklar

1.Aydoğdu K.  “ITIL’de Strategy-Design Süreçleri” . https://itilnotlari.wordpress.com/2016/04/08/itilde-strategy-design-surecleri/.

Son Erişim Zamanı: 8 Nisan 2016

2.Gürcan A.  “ITIL Nedir? Ne İşe Yarar?. http://www.mshowto.org/itil-nedir-ne-ise-yarar.html

Son Erişim Zamanı: 4 Şubat  2013

3.Ergen C. “Information Technology Infrastructure Library ITIL nedir?”.https://www.cozumpark.com/information-technology-infrastructure-library-itil-nedir/

Son Erişim Zamanı: 5 Mayıs 2010